« previous next »
Pages: [1]   Go Down

Author Topic: Crash with empty DLL target  (Read 8884 times)

Offline iw2nhl

  • Multiple posting newcomer
  • *
  • Posts: 116
  • BASIC, C, C++, Qt, bash
Crash with empty DLL target
« on: July 15, 2006, 03:42:34 pm »
Steps to reproduce:
1) Start codeblocks
2) New project from template "Empty project"
3) Give a name and leave everything else as default
4) New build target from template "Dynamic link library"
5) Give a name (I used 'dll') and leave everything else as default
6) Build
Result:
after some seconds in which everything seems freezed, a window shows up.
It is standard Windows error message for crashes:
<The instruction at "0x00000434" referenced memory at "0x00000434". The memory could not be "read".>
The previous line in the call stack is:
6194EB5A   call        ecx
with ecx = 1076 = 0x00000434 (but it varies every time)
Then a codeblocks.RPT is created.

NOTICE THIS:
If you re-execute the same steps without deleting the codeblocks.RPT file, the standard Windows error message is NOT shown, instead a new window is shown:
"Exception!"
And, in short, it says this:
- error at:
sdk\compilercommandgenerator.cpp, on line 101
- error message:
Compiler for target 'dll' is invalid!

Why the 2 different behaviours depending on the presence/absence of the "codeblocks.RPT" file?

OS:
Windows 2000 SP4
CodeBlocks version (nightly build):
Version 1.0 revision 2740 () gcc 3.4.5 Windows/unicode

codeblocks.RPT:
Code
-------------------

Error occured on Saturday, July 15, 2006 at 15:30:27.

C:\CodeBlocks\Installed\codeblocks.exe caused an Access Violation at location 00000434 Reading from location 00000434.

Registers:
eax=00000001 ebx=0022f04c ecx=00000434 edx=474e5543 esi=661784f8 edi=02447c90
eip=00000434 esp=0022f024 ebp=0022f060 iopl=0         nv up ei pl nz na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=0038  gs=0000             efl=00010202

Call stack:
00000434
6194EB5C  C:\CodeBlocks\Installed\codeblocks.dll:6194EB5C  _ZN7SQLexer6ReadIDEv
61944EB5  C:\CodeBlocks\Installed\codeblocks.dll:61944EB5  _ZN7SQLexer6ReadIDEv
617F5ED2  C:\CodeBlocks\Installed\codeblocks.dll:617F5ED2  _ZN24CompilerCommandGenerator4InitEP9cbProject
617ECD98  C:\CodeBlocks\Installed\codeblocks.dll:617ECD98  _ZN8Compiler4InitEP9cbProject
660D067B  C:\CodeBlocks\Installed\share\codeblocks\plugins\compilergcc.dll:660D067B  PluginSDKVersion
660D1720  C:\CodeBlocks\Installed\share\codeblocks\plugins\compilergcc.dll:660D1720  PluginSDKVersion
660D2237  C:\CodeBlocks\Installed\share\codeblocks\plugins\compilergcc.dll:660D2237  PluginSDKVersion
660D2315  C:\CodeBlocks\Installed\share\codeblocks\plugins\compilergcc.dll:660D2315  PluginSDKVersion
660D3FFA  C:\CodeBlocks\Installed\share\codeblocks\plugins\compilergcc.dll:660D3FFA  PluginSDKVersion
660C4D9F  C:\CodeBlocks\Installed\share\codeblocks\plugins\compilergcc.dll:660C4D9F  PluginSDKVersion
100AA808  C:\CodeBlocks\Installed\wxmsw26u_gcc_cb.dll:100AA808  _ZN12wxEvtHandler21ProcessEventIfMatchesERK21wxEventTableEntryBasePS_R7wxEvent
100AABCC  C:\CodeBlocks\Installed\wxmsw26u_gcc_cb.dll:100AABCC  _ZN16wxEventHashTable11HandleEventER7wxEventP12wxEvtHandler
100ABBA9  C:\CodeBlocks\Installed\wxmsw26u_gcc_cb.dll:100ABBA9  _ZN12wxEvtHandler12ProcessEventER7wxEvent
100ABB49  C:\CodeBlocks\Installed\wxmsw26u_gcc_cb.dll:100ABB49  _ZN12wxEvtHandler12ProcessEventER7wxEvent
100ABB49  C:\CodeBlocks\Installed\wxmsw26u_gcc_cb.dll:100ABB49  _ZN12wxEvtHandler12ProcessEventER7wxEvent
100ABB49  C:\CodeBlocks\Installed\wxmsw26u_gcc_cb.dll:100ABB49  _ZN12wxEvtHandler12ProcessEventER7wxEvent
100ABB49  C:\CodeBlocks\Installed\wxmsw26u_gcc_cb.dll:100ABB49  _ZN12wxEvtHandler12ProcessEventER7wxEvent
100ABB49  C:\CodeBlocks\Installed\wxmsw26u_gcc_cb.dll:100ABB49  _ZN12wxEvtHandler12ProcessEventER7wxEvent
100ABB49  C:\CodeBlocks\Installed\wxmsw26u_gcc_cb.dll:100ABB49  _ZN12wxEvtHandler12ProcessEventER7wxEvent
100ABB49  C:\CodeBlocks\Installed\wxmsw26u_gcc_cb.dll:100ABB49  _ZN12wxEvtHandler12ProcessEventER7wxEvent
100ABB49  C:\CodeBlocks\Installed\wxmsw26u_gcc_cb.dll:100ABB49  _ZN12wxEvtHandler12ProcessEventER7wxEvent
100ABB49  C:\CodeBlocks\Installed\wxmsw26u_gcc_cb.dll:100ABB49  _ZN12wxEvtHandler12ProcessEventER7wxEvent
100ABB49  C:\CodeBlocks\Installed\wxmsw26u_gcc_cb.dll:100ABB49  _ZN12wxEvtHandler12ProcessEventER7wxEvent
100ABB49  C:\CodeBlocks\Installed\wxmsw26u_gcc_cb.dll:100ABB49  _ZN12wxEvtHandler12ProcessEventER7wxEvent
100ABB49  C:\CodeBlocks\Installed\wxmsw26u_gcc_cb.dll:100ABB49  _ZN12wxEvtHandler12ProcessEventER7wxEvent
100ABB49  C:\CodeBlocks\Installed\wxmsw26u_gcc_cb.dll:100ABB49  _ZN12wxEvtHandler12ProcessEventER7wxEvent
100ABB49  C:\CodeBlocks\Installed\wxmsw26u_gcc_cb.dll:100ABB49  _ZN12wxEvtHandler12ProcessEventER7wxEvent
100ABB49  C:\CodeBlocks\Installed\wxmsw26u_gcc_cb.dll:100ABB49  _ZN12wxEvtHandler12ProcessEventER7wxEvent
100ABB49  C:\CodeBlocks\Installed\wxmsw26u_gcc_cb.dll:100ABB49  _ZN12wxEvtHandler12ProcessEventER7wxEvent
101B30A3  C:\CodeBlocks\Installed\wxmsw26u_gcc_cb.dll:101B30A3  _ZN11wxFrameBase14ProcessCommandEi
1013868F  C:\CodeBlocks\Installed\wxmsw26u_gcc_cb.dll:1013868F  _ZN7wxFrame13HandleCommandEttPv
10138DB6  C:\CodeBlocks\Installed\wxmsw26u_gcc_cb.dll:10138DB6  _ZN7wxFrame13MSWWindowProcEjjl
1010D6D0  C:\CodeBlocks\Installed\wxmsw26u_gcc_cb.dll:1010D6D0  _Z9wxWndProcP6HWND__jjl@16
77E4158F  C:\WINNT\system32\USER32.dll:77E4158F  __imp__GetViewportExtEx@8
77E41DC9  C:\WINNT\system32\USER32.dll:77E41DC9  __imp__GetViewportExtEx@8
77E41E7E  C:\WINNT\system32\USER32.dll:77E41E7E  __imp__GetViewportExtEx@8
100ED0A4  C:\CodeBlocks\Installed\wxmsw26u_gcc_cb.dll:100ED0A4  _ZN11wxEventLoop8DispatchEv
100ECE40  C:\CodeBlocks\Installed\wxmsw26u_gcc_cb.dll:100ECE40  _ZN11wxEventLoop3RunEv
10186AFE  C:\CodeBlocks\Installed\wxmsw26u_gcc_cb.dll:10186AFE  _ZN9wxAppBase8MainLoopEv
004046E4  C:\CodeBlocks\Installed\codeblocks.exe:004046E4
10043B67  C:\CodeBlocks\Installed\wxmsw26u_gcc_cb.dll:10043B67  _Z14wxUninitializev
100B3ADA  C:\CodeBlocks\Installed\wxmsw26u_gcc_cb.dll:100B3ADA  _Z7wxEntryP11HINSTANCE__S0_Pci
004014D8  C:\CodeBlocks\Installed\codeblocks.exe:004014D8
00467C7A  C:\CodeBlocks\Installed\codeblocks.exe:00467C7A
00401237  C:\CodeBlocks\Installed\codeblocks.exe:00401237
004012A8  C:\CodeBlocks\Installed\codeblocks.exe:004012A8
7C598989  C:\WINNT\system32\KERNEL32.dll:7C598989  ProcessIdToSessionId
Logged

Offline iw2nhl

  • Multiple posting newcomer
  • *
  • Posts: 116
  • BASIC, C, C++, Qt, bash
Re: Crash with empty DLL target
« Reply #1 on: July 18, 2006, 07:30:23 pm »
Anyone else can see this bug?

As a side note, with today's nigthly build the message is different and is always the same, indipendently if there is the "codeblocks.RPT" file or not.
Logged

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5529
Re: Crash with empty DLL target
« Reply #2 on: July 18, 2006, 07:56:24 pm »
I hope to look into it later this week.
Logged

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5529
Re: Crash with empty DLL target
« Reply #3 on: July 18, 2006, 10:02:48 pm »
I've done a first test : when looking at the generated cbp (after saving it first), there's no compiler specified :

            <Option compiler="" />

The same happens when you created a console target instead of the dll target in your example. So my first guess would be to say that the error is in the scripting wizards. Since they now create the cbp file.

Next to that, when you reopen that 'faulty' cbp, then CB will ask to specify a compiler. The ultimate correct thing foCB was to do this also after the 'bad' target generated from the wizards.
One could also argue, just use the compiler from the project level then, but this would mask the problem. Yeah, I know tell the user the entry was not correct and that the switch to project level is going to take place ;-)
But that brings us back to the point that CB did not see the mistake the first time around.

[EDIT] : well it could also be the surrounding code driving the scripts. But the scripts did not ask which compiler to use, and they should !!!
« Last Edit: July 18, 2006, 10:19:59 pm by killerbot »
Logged

Offline iw2nhl

  • Multiple posting newcomer
  • *
  • Posts: 116
  • BASIC, C, C++, Qt, bash
Re: Crash with empty DLL target
« Reply #4 on: July 18, 2006, 10:20:58 pm »
Surely it is better to remove the bug!
Anyway having a default behaviour for this bug is not a bad idea. It could use the project compiler, but show a message asking to report the bug to the plugin developer.
This would achive that:
1) C::B does not crash
2) the bug is not forgotten

What do you think about this?
Logged

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5529
Re: Crash with empty DLL target
« Reply #5 on: July 18, 2006, 10:23:02 pm »
I think the scripts should ask for a compiler !!! Always, maybe for this target I want to use another compiler then the project one. When the scripts do this --> there will be no bug at all ;-)
Logged

Offline iw2nhl

  • Multiple posting newcomer
  • *
  • Posts: 116
  • BASIC, C, C++, Qt, bash
Re: Crash with empty DLL target
« Reply #6 on: July 18, 2006, 10:25:29 pm »
Yes, I read your [EDIT] part after my post.
You are definetly right: the scripts should ask for a compiler!
Logged

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5529
Re: Crash with empty DLL target
« Reply #7 on: July 18, 2006, 10:47:38 pm »
I have a current workaround like this :

Code
wxString Wiz::GetTargetCompilerID()
{
	wxString CompilerId = CompilerFactory::GetDefaultCompilerID();
    if (m_pWizBuildTargetPanel)
    {
        CompilerId = m_pWizBuildTargetPanel->GetCompilerID();
        if(CompilerId == wxEmptyString)
        {
        	CompilerId = CompilerFactory::GetDefaultCompilerID();;
			// show message that no compiler stated and we falling back tpo the default one
        }
    }
    else
    {
    	// show message that no compiler stated and we falling back tpo the default one
    }
    return CompilerId;
}
The save(workaround) in the above mentioned examples is now carried out by that reassignemn of the default compiler set in CB. Might commit this code tomorrow, or could fall back on the project one. But note : this is a workaround, not the real place to fix.
Logged

Offline iw2nhl

  • Multiple posting newcomer
  • *
  • Posts: 116
  • BASIC, C, C++, Qt, bash
Re: Crash with empty DLL target
« Reply #8 on: July 18, 2006, 11:17:55 pm »
Ok, it seems right.
At least with this C::B does not crash!
When the scripts will be updated, a message can be added so that a similar bug can be found rapidly in the future.
Thanks for the fast solution!
Logged

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5529
Re: Crash with empty DLL target
« Reply #9 on: July 18, 2006, 11:22:02 pm »
no problem, tomorrow I will commit, but the solution will be at the call of this method. So a little change.
Logged

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5529
Re: Crash with empty DLL target
« Reply #10 on: July 19, 2006, 11:00:41 am »
done : revision 2770. (with feedback to the user)
Logged

Offline iw2nhl

  • Multiple posting newcomer
  • *
  • Posts: 116
  • BASIC, C, C++, Qt, bash
Re: Crash with empty DLL target
« Reply #11 on: July 19, 2006, 11:33:14 pm »
Perfect!
I've seen it in latest nigtly build changelog.

I was thinking this: before your workaround, it crashed. The crash was in the code you modified or it was code called later? Because if was the modified code, nothing to do, but if it crashed later, then could be added a 'if()' to test if variable is valid instead of crashing...
This is just an idea, I do not know the code ;-)
Logged
Pages: [1]   Go Up
« previous next »