View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004394 | Spring engine | Linux | public | 2014-05-16 03:07 | 2014-05-22 00:18 |
| Reporter | MajorBoredom | Assigned To | abma | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | closed | Resolution | unable to reproduce | ||
| Product Version | 96.0 | ||||
| Summary | 0004394: TranslateStacktrace provides inappropriate values to addr2line | ||||
| Description | rts/System/Linux/CrashHandler.cpp:309-313 Here the crash handler tries to take the offset values returned by backtrace_symbols and convert these into file:line pairs using addr2line. However, the clauses in this code range offer two possibilities for interpreting the offset as either a relative or absolute offset into the module in question. It was previously assumed here that the correct interpretation will cause addr2line to produce the appropriate "file:line#" format and that the wrong interpretation will simply produce "??:?" indicating that addr2line does not know the answer. However, this isn't always true. In the second case, our code will convert the absolute offset to a relative offset and then pass it to addr2line which will treat it as an absolute offset. Instead of "??:?" there is a chance that it will actually give a random "file:line#" pair that is plainly wrong and not part of the call stack. | ||||
| Steps To Reproduce | I have altered the stack trace output to reveal three things: (1) the backtrace_symbols() output (format is "module:offset") (2) the addr2line output using (1) as input (format is "file:line") (3) the result of libunwind's unw_getprocname() using (1) as input (format is just a function's symbol name) Comparison of these three outputs reveals that libunwind gets the correct answer just as addr2line does, however since TranslateStacktrace() calls addr2line twice for each frame, it often gets the wrong answer for one of these calls and substitutes it in. Furthermore, you can manually take the module:offset information from (1) and plug it into addr2line yourself without subtracting off the module's base address. This also produces an answer that is compatible with (3) showing that libunwind's answer is correct and that we are invoking addr2line in the wrong way. | ||||
| Additional Information | This probably went uncaught because some stack traces were imprecise anyway (when invoked by Watchdog). But it was also happening inside our SIGSEGV / SIGFPE signal handler where a precise frame was available, and could easily alter the displayed result to appear nonsensical. I am fixing this with the libunwind integration. | ||||
| Tags | No tags attached. | ||||
| Checked infolog.txt for Errors | |||||
|
|
I should also note that someone else had spotted this bug previously and had noted it in the comments preceding those lines, but it persists in 96.0.1+git etc. |
|
|
Is your code working? If so can you please push it to github so we can look at it? |
|
|
Yes it works, but I am holding off until I can determine that my code is not the cause of this other crash that I get in the UDPConnection code -- I can't see any reason atm for why they should be related. fwiw this issue is fixed in my libunwind code so we could just resolve it or mark it as related to the libunwind feature integration item. |
|
|
Please keep bug fixes and your libunwind patch separate. It would be much more effective if you would share your patch now when you fill in bug reports which are possible caused by your patch. In short: to much blabla, please show the code ;) |
|
|
I would only fix it as a bug if it is caused by my patch. It would be fatal to submit the patch into develop if it was causing this. If it is unrelated to my patch then I will just document it here and it can be fixed separately. |
|
|
sending a pull request for review != merge |
|
|
please don't waste my time, just show the code! |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2014-05-16 03:07 | MajorBoredom | New Issue | |
| 2014-05-16 03:09 | MajorBoredom | Note Added: 0013101 | |
| 2014-05-16 03:18 | Kloot | Relationship added | related to 0004387 |
| 2014-05-21 12:59 | abma | Note Added: 0013127 | |
| 2014-05-21 12:59 | abma | Assigned To | => abma |
| 2014-05-21 12:59 | abma | Status | new => feedback |
| 2014-05-21 22:32 | MajorBoredom | Note Added: 0013135 | |
| 2014-05-21 22:32 | MajorBoredom | Status | feedback => assigned |
| 2014-05-21 23:00 | abma | Note Added: 0013136 | |
| 2014-05-21 23:52 | MajorBoredom | Note Added: 0013137 | |
| 2014-05-21 23:53 | abma | Note Added: 0013138 | |
| 2014-05-21 23:54 | abma | Note Added: 0013139 | |
| 2014-05-22 00:18 | abma | Status | assigned => closed |
| 2014-05-22 00:18 | abma | Resolution | open => unable to reproduce |
