| Summary: | Callgrind: context.c:289 (vgCallgrind_push_cxt): Assertion 'cs->entry[cs->sp].cxt == 0' failed. | ||
|---|---|---|---|
| Product: | [Developer tools] valgrind | Reporter: | Bill King <bill.king> |
| Component: | callgrind | Assignee: | Josef Weidendorfer <josef.weidendorfer> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | crash | CC: | njn |
| Priority: | NOR | Keywords: | investigated, triaged |
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Attachments: | Last 1000 lines of callgrind output | ||
|
Description
Bill King
2007-03-14 04:06:54 UTC
This means that there is something wrong about the logic generating a new execution context (with e.g. the call chain). Event counters to collect are attached to these contexts. Looking at your case, it could be that there is a problem when a lot of thread switching is involved. However, this needs more details. Can you try to come up with the last few hundred lines of debug output you get with valgrind --tool=callgrind --ct-verbose=6 --ct-vstart=38500000 ... The 38500000 talks about when to start with the debug output, it is the number of basic blocks (BB) already executed, and the assertion in your case failed at BB 38988294. However, this only works if your code is roughly deterministic; and expect _huge_ quantities of output :-) Of course, it would be even better if you can come up with a small test case. A binary to send me in private would be enough, but I suspect I also would need all the .so's? Yep, all sorts of pain getting the environment set up. I'm not sure it could actually be pulled off in our sdk environment either. Seems to be an opensuse/version of libc/version of gcc bug, as suse9.3 wasn't suffering from the same issues on the same codebase. Will attach the last 1000 lines, have about 5.2G of output if you want more :) Created attachment 19980 [details]
Last 1000 lines of callgrind output
> ...
> - get_bbcc(BB 0x40008B0): BBCC 0x68A3C0C0
> >> pre_signal(TID 1, sig 11, alt_st no)
> cxtinfo_save(sig 0): collect Yes, jmps_passed 1
Oh. There is a segmentation fault happening in setup_bbcc(), after
the call to get_bbcc().
I think I have to come up with a patch adding a few assertions and
debug output at this place ...
It is really bad that you can not use a debugger for a valgrind tool,
as valgrind itself uses segfaults itself quite often :-(
BTW, this can not be some corruption done by your code? Ie, memcheck
runs cleanly?
Aye, memcheck and cachegrind run through cleanly. Josef, any ideas here? Unfortunately not. It would be a lot easier if I could reproduce it. Remote printf-Debugging is difficult. I'm closing crashing and similar bugs that are more than two years old. If you still see this problem with Valgrind 3.4.1 please reopen the bug report. Thanks. The qtopia product, while open source now, has been discontinued. So, it's up to you guys :) I can direct whoever wants to the source code, if they feel inclined, but I'd be sure I'm unable to replicate this any more (code has moved on, as has valgrind). Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone! This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone! |