Bug 42010 - resume_callback assertion `lp->step' failed
Summary: resume_callback assertion `lp->step' failed
Alias: None
Product: Red Hat Raw Hide
Classification: Retired
Component: gdb   
(Show other bugs)
Version: 1.0
Hardware: i386 Linux
Target Milestone: ---
Assignee: Trond Eivind Glomsrxd
QA Contact: Aaron Brown
Depends On:
TreeView+ depends on / blocked
Reported: 2001-05-23 17:59 UTC by John Weidman
Modified: 2007-04-18 16:33 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-05-30 16:47:52 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

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'
An internal GDB error was detected.  This may make further
debugging unreliable.  Continue this debugging session? (y or n) 

How reproducible:

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.

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.

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