Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development

unknown exception

<< < (3/17) > >>

grv575:
Adding that (editormanager.cpp:628) null check doesn't stop it from going off!

The odd thing is that it's the line
if (sel == -1)

that dies and triggers the exception (not the line above it):


--- Code: ---0x60538f8c <_ZN13EditorManager15GetActiveEditorEv+54>:  mov    eax,DWORD PTR [ebp+8]
0x60538f8f <_ZN13EditorManager15GetActiveEditorEv+57>:  mov    eax,DWORD PTR [eax+56]
0x60538f92 <_ZN13EditorManager15GetActiveEditorEv+60>:  mov    edx,DWORD PTR [eax]
0x60538f94 <_ZN13EditorManager15GetActiveEditorEv+62>:  add    edx,0x308
0x60538f9a <_ZN13EditorManager15GetActiveEditorEv+68>:  mov    eax,DWORD PTR [ebp+8]
0x60538f9d <_ZN13EditorManager15GetActiveEditorEv+71>:  mov    eax,DWORD PTR [eax+56]
0x60538fa0 <_ZN13EditorManager15GetActiveEditorEv+74>:  mov    DWORD PTR [esp],eax
0x60538fa3 <_ZN13EditorManager15GetActiveEditorEv+77>:  mov    eax,DWORD PTR [edx]
0x60538fa5 <_ZN13EditorManager15GetActiveEditorEv+79>:  call   eax
0x60538fa7 <_ZN13EditorManager15GetActiveEditorEv+81>:  mov    DWORD PTR [ebp-4],eax
0x60538faa <_ZN13EditorManager15GetActiveEditorEv+84>:  cmp    DWORD PTR [ebp-4],0xffffffff

(gdb) si
gdb: child_resume.SetThreadContext: thread 1432.0xaec
ContinueDebugEvent (cpid=1432, ctid=2796, DBG_CONTINUE);
gdb: kernel event for pid=1432 tid=2796 code=EXCEPTION_DEBUG_EVENT)
gdb: Target exception EXCEPTION_SINGLE_STEP at 0x60538fa5
0x60538fa5      629         if (sel == -1)
(gdb) si
gdb: child_resume.SetThreadContext: thread 1432.0xaec
ContinueDebugEvent (cpid=1432, ctid=2796, DBG_CONTINUE);
gdb: kernel event for pid=1432 tid=2796 code=EXCEPTION_DEBUG_EVENT)
gdb: Target exception EXCEPTION_SINGLE_STEP at 0xfeeefeee
0xfeeefeee in ?? ()

--- End code ---

Not sure why it's making a function call (call [eax]) to get sel off the stack...?

right before it crashes:

--- Code: ---(gdb)
gdb: child_resume.SetThreadContext: thread 3400.0x144
ContinueDebugEvent (cpid=3400, ctid=324, DBG_CONTINUE);
gdb: kernel event for pid=3400 tid=324 code=EXCEPTION_DEBUG_EVENT)
gdb: Target exception EXCEPTION_SINGLE_STEP at 0x60538fa3
0x60538fa3      629     ;
(gdb) i r
eax            0x17252b8        24269496
ecx            0x1      1
edx            0x211bbf8        34716664
ebx            0x13d4cb8        20794552
esp            0x22eca4 0x22eca4
ebp            0x22ecbc 0x22ecbc
esi            0x4a5030 4870192
edi            0x22eea4 2289316
eip            0x60538fa3       0x60538fa3
eflags         0x202    514
cs             0x1b     27
ss             0x23     35
ds             0x23     35
es             0x23     35
fs             0x3b     59
gs             0x0      0
(gdb) p sel
$19 = 2289316
(gdb) p/x
$20 = 0x22eea4

--- End code ---

so sel never gets assigned to (it's the same value at the beginning of the function).

m_pNotebook is valid (non null) though:

p m_pNotebook
$25 = (struct wxNotebook *) 0x1725008

p &m_pNotebook->GetSelection()
does crash gdb though....accessing 0x00000000, so something's not right.

280Z28:
How did you get it to load in the debugger??

I keep getting this  :x :x

http://forums.codeblocks.org/index.php?topic=1653.0

Only this time it's not with bf2.cpp, it's with the Code::Blocks files.

grv575:
hum.  just out of curiosity I changed it to:


--- Code: ---EditorBase* EditorManager::GetActiveEditor()
{
    SANITY_CHECK(0L);
    ///int sel = m_pNotebook->GetSelection();
    int sel;
    sel = m_pNotebook->GetSelection();
    if (sel == -1)
        return 0;

--- End code ---

sdk/editormanager.cpp:628

And now it runs flawlessly, no more exception.  So 1) is there something about local variable initializers that I don't get...why aren't they equivalent???   and 2) can the code be changed to not use a default initializer and use the old c89 (?) style like above?  Seems to fix the problem (but I'd still like to know why).

280Z28:
They are equivalent. You have a buffer overflow corrupting your memory somewhere and that line changed the code enough that you aren't seeing it... for now. But it's still there.

grv575:
Yeah, I just changed it back and forth, and now it compiles to the same code...so no idea

Navigation

[0] Message Index

[#] Next page

[*] Previous page