Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 31712

Summary: gdb-5.0-13 has trouble with ElectricFence-2.2.2-7
Product: [Retired] Red Hat Linux Reporter: Jonathan Kamens <h1k6zn2m>
Component: gdbAssignee: Trond Eivind Glomsrxd <teg>
Status: CLOSED RAWHIDE QA Contact: Aaron Brown <abrown>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.0   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2001-11-28 22:57:39 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jonathan Kamens 2001-03-13 20:58:59 UTC
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>
[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>

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 23:38:38 UTC
The last part is still a problem...

Comment 2 Jonathan Kamens 2001-03-15 01:10:38 UTC
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 21:07:39 UTC
That's because efence now uses threads.

Comment 4 Trond Eivind Glomsrxd 2001-07-30 20:13:13 UTC
Still a problem with current gdb CVS.

Comment 5 Trond Eivind Glomsrxd 2001-11-28 22:57:32 UTC
Still a problem with gdb 5.1

Comment 6 Trond Eivind Glomsrxd 2002-05-07 22:16:40 UTC
Fixed in gdb 5.2.