Bug 42010

Summary: resume_callback assertion `lp->step' failed
Product: [Retired] Red Hat Raw Hide Reporter: John Weidman <johnw>
Component: gdbAssignee: Trond Eivind Glomsrxd <teg>
Status: CLOSED WORKSFORME QA Contact: Aaron Brown <abrown>
Severity: medium Docs Contact:
Priority: medium    
Version: 1.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-05-30 16:47:52 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 John Weidman 2001-05-23 17:59:17 UTC 
From Bugzilla Helper:
User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.2.14-5.0-bigphys i686)

Description of problem:
when running a multi-threaded program under gdb I get an assertion failure:

lin-lwp.c:409: gdb-internal-error: resume_callback: Assertion `lp->step'
failed.
An internal GDB error was detected.  This may make further
debugging unreliable.  Continue this debugging session? (y or n) 



How reproducible:
Sometimes

Steps to Reproduce:
1. I don't have a standalone example that reproduces this.  I'm running a
program that I'm developing.  It starts by creating 256 threads and in
thoses threads there are some mallocs and frees.
2.
3.
	

Actual Results:  gdb assertion failure

Expected Results:  No assertion failure

Additional info:

I see the assertion failure when I step through the code with gdb.  Not
sure if it happens when not stepping
Comment 1 Trond Eivind Glomsrxd 2001-05-23 18:03:42 UTC 
Which version of gdb?
Comment 2 Trond Eivind Glomsrxd 2001-05-23 18:08:44 UTC 
(BTW: The 5.0rh-9 RPMs at http://people.redhat.com/teg/gdb/ (and soon/already in
Rawhide) has lots of fixes for threads).
Comment 3 John Weidman 2001-05-23 18:37:01 UTC 
This is was from gdb-5.0rh-8, but I also pulled the latest gdb snapshot,
gdb+dejagnu-20010523, and the problem still occurs.
Comment 4 Trond Eivind Glomsrxd 2001-05-23 18:41:40 UTC 
Can you try this on a RHL 7.1 system, to see if glibc and kernel makes a
difference? The 5.0rh-9 no longer has a limit of maximum 32 threads to debug...

If this doesn't work, a test case is essential.
Comment 5 Trond Eivind Glomsrxd 2001-06-14 15:42:44 UTC 
Closed due to lack of reproducible testcase. Reopen if one becomes available.