Bug 122021 - Assertion failure in gdb when trying to debug Evolution
Assertion failure in gdb when trying to debug Evolution
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: gdb (Show other bugs)
rawhide
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Jan Kratochvil
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-04-29 15:50 EDT by Dave Malcolm
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-08-15 16:02:43 EDT
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 Dave Malcolm 2004-04-29 15:50:14 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040312

Description of problem:
When attempting to debug Evolution (complex, multithreaded app), I
often get this error:
/usr/src/build/379942-i386/BUILD/gdb+dejagnu-20040223/gdb/lin-lwp.c:624:
internal-error: wait_lwp: Assertion `pid == GET_LWP (lp->ptid)' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.


Version-Release number of selected component (if applicable):
gdb-6.0post-0.20040223.8

How reproducible:
Sometimes

Steps to Reproduce:
1. Run Emacs
2. Invoke gdb on my local build of evolution within Emacs; try
debugging evolution.
3. After a while (perhaps 2 minutes), this error will generally appear.


Actual Results: 
/usr/src/build/379942-i386/BUILD/gdb+dejagnu-20040223/gdb/lin-lwp.c:624:
internal-error: wait_lwp: Assertion `pid == GET_LWP (lp->ptid)' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.

Additional info:
Comment 1 Elena Zannoni 2004-09-01 14:55:05 EDT
Does this still happen with a more recent gdb rpm?
Comment 2 Jan Kratochvil 2006-07-25 08:23:32 EDT
To be CLOSED-INSUFFICIENT_DATA (why it was not resolved this way after the
timeout automatically?).
Otherwise it would become CLOSED-CURRENTRELEASE anyway.

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