Code::Blocks Forums

Developer forums (C::B DEVELOPMENT STRICTLY!) => Development => Topic started by: MortenMacFly on December 21, 2007, 02:48:34 pm

Title: Batch builds currently broken in SVN
Post by: MortenMacFly on December 21, 2007, 02:48:34 pm

I just realised that batch builds seem to be broken in SVN (r4741). If I try I see a window, then a message box and if I hit OK C::B just crashes. The log is here:

Code

6286B5C7  C:\WINDOWS\system32\wxmsw28u_gcc_custom.dll:6286B5C7  _ZN10wxListCtrl12SetItemStateElll
64BFF63D  C:\Devel\CodeBlocks\src\devel\share\codeblocks\plugins\compiler.dll:64BFF63D  CompilerMessages::FocusError(int)  C:/Devel/CodeBlocks/src/plugins/compilergcc/compilermessages.cpp:55
64BFCA44  C:\Devel\CodeBlocks\src\devel\share\codeblocks\plugins\compiler.dll:64BFCA44  CompilerGCC::OnJobEnd(unsigned, int)  C:/Devel/CodeBlocks/src/plugins/compilergcc/compilergcc.cpp:3568
64BFBD7A  C:\Devel\CodeBlocks\src\devel\share\codeblocks\plugins\compiler.dll:64BFBD7A  CompilerGCC::OnGCCTerminated(CodeBlocksEvent&)  C:/Devel/CodeBlocks/src/plugins/compilergcc/compilergcc.cpp:3454
(...more follow...)

Can someone confirm the issue?
With regards, Morten.

Title: Re: Batch builds currently broken in SVN
Post by: MortenMacFly on December 21, 2007, 02:54:30 pm

...OK - they *are* broken as "control" is zero in the code pointed to in the previous post. :-(

Title: Re: Batch builds currently broken in SVN
Post by: killerbot on December 21, 2007, 02:57:48 pm

yes, several issues. On WINDOWS :


1) right click in explorer on a cbp and for example choose rebuild --> grey panel (no logs showing in it), and then the message box saying it finished)

2) I call CB with command line options for a nightly build system --> since I updated to a post 'new' log mechanism a few days ago, each night CRASH

Code

Error occured on Thursday, December 20, 2007 at 20:09:41.

C:\CodeBlocks\src\output\codeblocks.exe caused an Access Violation at location 1016bb17 in module C:\CodeBlocks\src\output\wxmsw28u_gcc_cb.dll Reading from location 000000cd.

Registers:
eax=00000006 ebx=00000006 ecx=0022f348 edx=00000000 esi=0022f348 edi=0022f37c
eip=1016bb17 esp=0022f328 ebp=0022f3a0 iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010206

Call stack:
1016BB17  C:\CodeBlocks\src\output\wxmsw28u_gcc_cb.dll:1016BB17  _ZN10wxListCtrl12SetItemStateElll
64BF870D  C:\CodeBlocks\src\output\share\codeblocks\plugins\compiler.dll:64BF870D
64BF5B12  C:\CodeBlocks\src\output\share\codeblocks\plugins\compiler.dll:64BF5B12
64BF4E48  C:\CodeBlocks\src\output\share\codeblocks\plugins\compiler.dll:64BF4E48
100C7F55  C:\CodeBlocks\src\output\wxmsw28u_gcc_cb.dll:100C7F55  _ZN12wxEvtHandler21ProcessEventIfMatchesERK21wxEventTableEntryBasePS_R7wxEvent
100C82AC  C:\CodeBlocks\src\output\wxmsw28u_gcc_cb.dll:100C82AC  _ZN16wxEventHashTable11HandleEventER7wxEventP12wxEvtHandler
100C9279  C:\CodeBlocks\src\output\wxmsw28u_gcc_cb.dll:100C9279  _ZN12wxEvtHandler12ProcessEventER7wxEvent
100C9099  C:\CodeBlocks\src\output\wxmsw28u_gcc_cb.dll:100C9099  _ZN12wxEvtHandler20ProcessPendingEventsEv
10001BF4  C:\CodeBlocks\src\output\wxmsw28u_gcc_cb.dll:10001BF4  _ZN12wxAppConsole20ProcessPendingEventsEv
105C3C75  C:\CodeBlocks\src\output\wxmsw28u_gcc_cb.dll:105C3C75  _ZN18wxHtmlSearchEngineD1Ev
7E41F84A  C:\WINDOWS\system32\USER32.dll:7E41F84A  EnableMenuItem
7E41F7F6  C:\WINDOWS\system32\USER32.dll:7E41F7F6  EnableMenuItem
7E41F94B  C:\WINDOWS\system32\USER32.dll:7E41F94B  CallNextHookEx
7C90EAE3  C:\WINDOWS\system32\ntdll.dll:7C90EAE3  KiUserCallbackDispatcher
1010EBC4  C:\CodeBlocks\src\output\wxmsw28u_gcc_cb.dll:1010EBC4  _ZN11wxEventLoop8DispatchEv
101E6986  C:\CodeBlocks\src\output\wxmsw28u_gcc_cb.dll:101E6986  _ZN17wxEventLoopManual3RunEv
1015DA8B  C:\CodeBlocks\src\output\wxmsw28u_gcc_cb.dll:1015DA8B  _ZN8wxDialog9ShowModalEv
00405706  C:\CodeBlocks\src\output\codeblocks.exe:00405706
00403BC6  C:\CodeBlocks\src\output\codeblocks.exe:00403BC6
00462A30  C:\CodeBlocks\src\output\codeblocks.exe:00462A30
1004E2F9  C:\CodeBlocks\src\output\wxmsw28u_gcc_cb.dll:1004E2F9  _Z14wxUninitializev
100D1D7C  C:\CodeBlocks\src\output\wxmsw28u_gcc_cb.dll:100D1D7C  _Z7wxEntryP11HINSTANCE__S0_Pci
004017DA  C:\CodeBlocks\src\output\codeblocks.exe:004017DA
0045EEAA  C:\CodeBlocks\src\output\codeblocks.exe:0045EEAA
00401237  C:\CodeBlocks\src\output\codeblocks.exe:00401237
00401288  C:\CodeBlocks\src\output\codeblocks.exe:00401288
7C816FD7  C:\WINDOWS\system32\kernel32.dll:7C816FD7  RegisterWaitForInputIdle

Title: Re: Batch builds currently broken in SVN
Post by: MortenMacFly on December 21, 2007, 03:28:36 pm

Quote from: killerbot on December 21, 2007, 02:57:48 pm

1) right click in explorer on a cbp and for example choose rebuild --> grey panel (no logs showing in it), and then the message box saying it finished)

I have just realised this, too after...

Quote from: killerbot on December 21, 2007, 02:57:48 pm

2) I call CB with command line options for a nightly build system --> since I updated to a post 'new' log mechanism a few days ago, each night CRASH

...I have fixed this crash. Seems like the layout mechanism is broken. If you manually resize the log window the loggers appear but they are *not* present (means the UI is not instantiated) if you don't -> thus, the crash.

Seems there was aleady a guy who reported this, too:
http://forums.codeblocks.org/index.php/topic,7478.msg56788.html#msg56788

I'm afraid I don't geht why the logger UI is not working. I introduced a m_pBatchBuildDialog->FitInside() in MainFrame::SetupGUILogging() for the batch build dialog but this made things worse: The logs are visible but the whole dialog is damn small. How I love siizers... ;-) For now I need to stop to go home but I believe Yiannis can fix this in a second so when I'm home it may already been resolved. ;-)

As for the crash I simply added an if (control) check in void CompilerMessages::FocusError(int nr).

With regards, Morten.

Title: Re: Batch builds currently broken in SVN
Post by: thomas on December 21, 2007, 08:24:34 pm

Please don't blame the logging system. You're just getting what everyone wanted.

The new logging system was made mainly to remove all these hacks, and to make it possible to write easy code with no frills and workarounds.
Instead, the code is now more queer than ever. Inserting that if(control) may prevent the crash, but it doesn't really fix anything, it's still all screwed up. You cannot even tell for sure what is added to which window when.

Title: Re: Batch builds currently broken in SVN
Post by: MortenMacFly on December 21, 2007, 08:43:36 pm

Quote from: thomas on December 21, 2007, 08:24:34 pm

Please don't blame the logging system.

I don't! I blame compilermessages.cpp. ;-)

Quote from: thomas on December 21, 2007, 08:24:34 pm

Inserting that if(control) may prevent the crash, but it doesn't really fix anything, it's still all screwed up.

I agree on that completely. I said it's a workaround for now until a proper fix. My problem is that I didn't write the logger and the modification either.- So I believe for me it's even harder to understand that for you... Hehe... ;-)

Title: Re: Batch builds currently broken in SVN
Post by: MortenMacFly on December 21, 2007, 08:46:28 pm

Quote from: thomas on December 21, 2007, 08:24:34 pm

You cannot even tell for sure what is added to which window when.

I agree here, too. But: For the batch build I wonder if this is really what we want then. We want for sure that the log messages are printed on the screen. So why do we use a logger here at all then?! This makes me ask in general: If we can't rely on the loggers (which is OK for a logger) why do we print important messages to a logger then, even in "non-batch-build-C::B"? What would you suppose to do instead, Thomas?!

Title: Re: Batch builds currently broken in SVN
Post by: thomas on December 21, 2007, 10:27:14 pm

What I wanted is this:

a) normal startup:
- the application starts, and creates a main frame
- all plugins are loaded, plugins can install whatever loggers they might need later (no GUI available yet)
- the main frame queries the installed loggers for controls
- if a logger has a control, it's added to the info pane (now GUI is available, and output is visible)

b) batch startup:
- the application either does not create a main frame at all (not needed) or, if that is a problem for some reason, creates one but doesn't show it
- only the compiler plugin (and maybe 1-2 other select plugins, such as EnvVar) is loaded, as nothing else is needed
- a simple window is created, just a plain normal window
- the compiler's log is asked for a control, which is added to the window (everything else is just ignored, it doesn't matter)
- batch build runs, finishes, compiler plugin unregisters its logger, the window is closed, the application is closed
- no need to do anything else -- the window will delete the control, and LogManager will delete the Logger
- if we are sure that the compiler does not output anything after the build is finished (a reasonable assumption) then we don't even need to unregister the Logger (that would keep an invalid pointer dangling around for a few milliseconds, but if it is guaranteed not to be accessed, that's ok)
- the compiler plugin (or any other component) ideally does not even know that a batch build is running (well, it still may have to know if no main frame is created, because then no menu entries and toolbar buttons can be added, but that would be trivial to check).

And what we have is this:
a) and b) likewise:
- a main frame is created and listens to messages, and in response adds controls to the info pane which is owned by either the main frame or BatchLogDialog (and, this class does not even seem to exist at all, I could not find it with code completion lookup, nor with global file search ---> how does this compile at all??? I'm clueless...)
- there are a lot of separate branches for either "normal" or "batch" mode in all involved components, although none of those components should actually need to bother
- everything is dynamic and cool, but it does not work, and it's a pain to figure why

This is another example for complexity being not a good thing. If we absolutely have to load/unload plugins at runtime (I personally don't see why we need this), there is still no reason why you have to add/remove loggers dynamically too.
It is perfectly acceptable that a custom logger (or rather, its control) stays visible if you unload a plugin at runtime (the user can still hide the tab if he doesn't want to see it), and it is perfectly acceptable that no custom logger is visible if a plugin was dynamically loaded after startup. For one reason, almost no plugin needs to install a custom logger anyway, and if it is really so utterly important, then the user can relaunch the application quickly, this is really no big burden.
Personally, I don't even think it is asked too much to relaunch the application to load a new plugin or to unload another one, it keeps things simple and failsafe, plus, you don't load/unload plugins 35 times per day anyway. Firefox which I'm using to type this text right now loads its plugins at startup, and there is nothing wrong with it.

Regarding non-Loggers added to the InfoPane, one could argue. Although I don't deem it good to add/remove controls at runtime (and move it between different panes), if this is absolutely wanted... ok then. Again, I would prefer things to be simple, but... there is one difference. Here we're talking about something that is entirely optional and entirely proprietary. What makes it acceptable is that the application does not know anything or give a crap about the pointer it is given. Thus, the complexity doesn't lie in the application or the managers.

Title: Re: Batch builds currently broken in SVN
Post by: killerbot on December 22, 2007, 09:42:11 am

my biggest question is, where can we start to fix this ?
Regarding from things good or bad; they have worked, and now it crashes. Why can I crash now, and how to fix this ?

In the example of batch build, we have for sure 2 (new?) issues :

- the compiler output is not visible, where this use to work in the past (why is that windows plain grey now)
- the whole thing crashes

PS: How can I right click on a cbp file and have it build by CB in linux (more specifically OpenSuse 10.3 or 10.2, so I can check if we have similar issues on linux), according to Yiannis it works in linux.

Title: Re: Batch builds currently broken in SVN
Post by: Jenna on December 22, 2007, 10:21:47 am

Quote from: killerbot on December 22, 2007, 09:42:11 am

...
In the example of batch build, we have for sure 2 (new?) issues :
...
- the compiler output is not visible, where this use to work in the past (why is that windows plain grey now)

The grey window appears since some releases. I don't know exactly when (but I try to investigate), but I thought it was a problem with my virtual w2k.
The crash does not happen for me.

On linux when I execute

Code

codeblocks -ns --no-batch-window-close --build CodeBlocks-unix.cbp

it works without problems, and I have two tabs in the window ("Build Log" and "Script Console").
On windows the same commandline does not work.
Another difference is that that on win the dialog seems to run asynchron, that means after running the commandthe prompt immediately returns and then the dialog opens.
On Linux all output also goes to console and the prompt does not reappear before the dialog is closed.

What I want to say is, that there seems to be a difference between this two OSes and even between different installations and/or versions on/of win.

Title: Re: Batch builds currently broken in SVN
Post by: thomas on December 22, 2007, 12:14:30 pm

Quote

my biggest question is, where can we start to fix this ?
Regarding from things good or bad; they have worked, and now it crashes. Why can I crash now, and how to fix this ?

That's exactly the problem, I don't know where to start. There is actually no reason why it could/should crash.
You cannot delete Loggers in an unsafe way, the API only lets you delete a Logger by replacing it with a NullLogger. So, there is never an invalid pointer, only a pointer to an object that does nothing.
Thus, the only thing that can be the "reason" for a crash is the wxTextCtrl, but this one is owned by the window (which deletes it when the window closes, at which time that's a legal thing to do). This actually cannot crash either, except if something/someone logs to the compiler log after the batch window has been closed (or worse: writes to the wxTextCtrl directly... ouch). Although there is no reason why this should happen, it could be prevented for good by deleting the Logger when the build has finished, since that will severe the link to the wxTextCtrl.

Quote

- the compiler output is not visible, where this use to work in the past (why is that windows plain grey now)

One easy and obvious reason could be "window is not getting update events". That is because it works just fine once you resize the window. The control is definitively there, and it sure logs everything as it should. Only for some reason the window never paints it.
Maybe the window needs to get an update event or a show event or something... though this should normally work just by calling Show() and doing nothing else? Maybe you have to wxYield() once to give the message pump a chance to run... no idea.

Quote

- the whole thing crashes

Does not happen here. Did not have it happen a single time trying 20 times.
Although Martin seems to have fixed it with this if(control), the real reason may be a different one. Since you have the crash and I don't, and the major difference between our systems is that I do not use anything but core, there is a chance that a third-party plugin causes it (not sure which ones are loaded for batch builds at all). Can you test if it still occurs after you disable them all?

Title: Re: Batch builds currently broken in SVN
Post by: killerbot on December 24, 2007, 07:59:26 pm

in rev 4750 our big boss fixed it  :D :D :D