Bug 31712 - gdb-5.0-13 has trouble with ElectricFence-2.2.2-7
gdb-5.0-13 has trouble with ElectricFence-2.2.2-7
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: gdb (Show other bugs)
7.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Trond Eivind Glomsrxd
Aaron Brown
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-03-13 15:58 EST by Jonathan Kamens
Modified: 2007-04-18 12:32 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-11-28 17:57:39 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jonathan Kamens 2001-03-13 15:58:59 EST
I'm running a program under gdb-5.0-13 which was linked against libefence
from ElectricFence-2.2.2-7.  Here's the output I see in the gdb window
(there's no output from the program because it's an X program):

(gdb) run -name linuxxrn -iconName linuxxrn
Starting program: /c/build/xrn/xrn -name linuxxrn -iconName linuxxrn
[New Thread 1024 (LWP 4493)]

  Electric Fence 2.2.0 Copyright (C) 1987-1999 Bruce Perens
<bruce@perens.com>
[New Cannot find thread 2049: invalid thread handle
(gdb) where
Couldn't get registers: No such process.

The "[New Cannot find thread..." message comes up quite a while after the
program starts running.  My best guess is that the program is encountering
a memory problem and ElectricFence is detecting it and trying to throw
control back to the debugger, but that isn't working somehow.

I recently upgraded both ElectricFence and gdb, so I don't know if one of
these or the other is the one causing the problem.  I'm going to try
downgrading ElectricFence and see if the problem goes away.

This may or may not be a related problem.... If I link this program against
efence:

include <malloc.h>

main()
{
  char *foo = malloc(1);
  memset(foo, 0, 2048);
}

run it under gdb and then try to reload it, watch what happens:

(gdb) run
Starting program: /tmp/a.out
[New Thread 1024 (LWP 9575)]

  Electric Fence 2.2.0 Copyright (C) 1987-1999 Bruce Perens
<bruce@perens.com>

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 9575)]
0x400aac27 in memset () from /lib/libc.so.6
(gdb) kill
Kill the program being debugged? (y or n) y
(gdb) file a.out
Load new symbol table from "a.out"? (y or n) y
Reading symbols from a.out...done.
warning: Cannot initialize thread debugging library: generic error
(gdb)

That last warning may be a problem.
Comment 1 Trond Eivind Glomsrxd 2001-03-14 18:38:38 EST
The last part is still a problem...
Comment 2 Jonathan Kamens 2001-03-14 20:10:38 EST
I haven't seen any trouble since I downgraded to ElectricFence-2.1-3.  This
suggests that perhaps EF is doing something wrong.  Or perhaps EF is doing
something completely legitimate which gdb isn't prepared to handle properly.
Comment 3 Trond Eivind Glomsrxd 2001-03-16 16:07:39 EST
That's because efence now uses threads.
Comment 4 Trond Eivind Glomsrxd 2001-07-30 16:13:13 EDT
Still a problem with current gdb CVS.
Comment 5 Trond Eivind Glomsrxd 2001-11-28 17:57:32 EST
Still a problem with gdb 5.1
Comment 6 Trond Eivind Glomsrxd 2002-05-07 18:16:40 EDT
Fixed in gdb 5.2.

Note You need to log in before you can comment on or make changes to this bug.