On Tue, Sep 05, 2017 at 03:15:12PM +0200, Jiri Kosina wrote: > Hi Josh, > > I just got the below stack trace with current Linus' tree with ORC > unwinder enabled: > > [ 8.652765] Call Trace: > [ 8.652767] dump_stack+0x7c/0xbf > [ 8.652769] print_circular_bug+0x2d3/0x2e0 > [ 8.652771] check_prev_add+0x666/0x700 > [ 8.652772] ? print_bfs_bug+0x40/0x40 > [ 8.652775] lock_commit_crosslock+0x3f1/0x570 > [ 8.652777] complete+0x24/0x60 > [ 8.652779] __kthread_parkme+0x42/0x90 > [ 8.652780] smpboot_thread_fn+0x92/0x210 > [ 8.652782] kthread+0x145/0x180 > [ 8.652783] ? sort_range+0x20/0x20 > [ 8.652785] ? kthread_create_on_node+0x40/0x40 > [ 8.652787] ret_from_fork+0x2a/0x40 > > Please note the kthread_create_on_node(), sort_range() and print_bfs_bug() > entries ... I believe they actually shouldn't be there at all. All of them > are at the last byte belonging to the function. Am I missing something?
The question marks are still supposed to be there. They show any text addresses found on the stack that weren't otherwise found by the unwinder. 99.9% of the time, they're left over from a previous call chain, and should be ignored. They can be confusing, but IIRC, Linus wants to keep them because: a) If the unwinder gets confused, they'll still be printed. b) For some really sneaky bugs, it can give a few clues about what happened *before* the current trace. Personally I've never seen (b), but (a) is definitely a good reason. Note that while the "unreliable" addresses are shown for splats, they're *not* reported by the unwinder for all its other uses like livepatch, perf, /proc/<pid>/stack, etc. -- Josh
