This content has been marked as final. Show 6 replies
Address field at the bottom of the disassembly is supposed for that... Unfortunately the field does not accept expressions, I filed https://netbeans.org/bugzilla/show_bug.cgi?id=218612 for that and hopefully will fix it today. Until you get the fix you can enter the expression into Expression Evaluation window and use the address it provides in the disassembly.
I don't understand. If the crash is in foo::bar+0x51 then the disassembly window should automatically
be showing that function in the editor area.
You might have to do some 'down's or click on the top frame in the stack view to see that disassembly
because dbx will normally attempt to find some source up the stack and show that preferentially.
(See `help dbxenv` under dbxenv stack_find_source).
Sorry, I wasn't clear enough.
I'm not debugging in Studio when the crash appears, most often it's not me who encounters the crash at all. I just read about it in a bug report. I don't have a reproducer and I don't have a core file.
So all I want to do is to open Studio in regular edit mode (no debugger) and go to the instruction to see where the crash happened. Especially when I have several crash reports that have crashed in the same function but at different places it would be helpful to see if the crashes are related or in completely different parts of the code.
From the dbx cmdline you can do something like this:
(dbx) debug a.out
(dbx) func PSPromotionManager::copy_to_survivor_space
I would've expected the IDE to honor the 'func' and bring the disassembly window to bear on
copy_to_survivor_space but it doesn't. It works for source code but not non-g code.
There's also other issues with disassembly window modality. E.g. I can say
(dbx) func foo
# IDE shows source
# In IDE switch to disassembly it shows disassembly but for what's on the stack, not foo.