wxWidgets 3.0.0 released!

[oBFusCATed]

I'm able to reproduce the problem using the minimal sample in wx30's relatively latest git.

Here is the patch:

Code Select Expand


diff --git a/samples/minimal/minimal.cpp b/samples/minimal/minimal.cpp
index a78e462..dc0709a 100644
--- a/samples/minimal/minimal.cpp
+++ b/samples/minimal/minimal.cpp
@@ -123,6 +123,7 @@ bool MyApp::OnInit()
     // few common command-line options but it could be do more in the future
     if ( !wxApp::OnInit() )
         return false;
+//    wxExecute(wxT("gcc -dumpversion"), wxEXEC_SYNC);//|wxEXEC_NOEVENTS);

     // create the main application window
     MyFrame *frame = new MyFrame("Minimal wxWidgets App");
@@ -197,4 +198,5 @@ void MyFrame::OnAbout(wxCommandEvent& WXUNUSED(event))
                  "About wxWidgets minimal sample",
                  wxOK | wxICON_INFORMATION,
                  this);
+    wxExecute(wxT("gcc -dumpversion"), wxEXEC_SYNC);//|wxEXEC_NOEVENTS);
}


In order to reproduce this.
1. Apply the patch
2. Create a project for the minimal sample
3. Try to debug the sample using C::B

Results:
1. The sample hang at both wxExecute calls
2. The gcc executable is left as zombie process, so something doesn't close correctly
3. wxExecute never exits

I've not yet contacted the wx devs, but I'll do it as soon as I gather more data. Hopefully it is not reproducable on newer linuxes only.


@Jens and any dev or Linux user willing to try: Could you try to reproduce this problem?

[BlueHazzard]

here on Linux Mint 15 your example works with latest wxWidgets svn. No blocked or zombie process in debugging or running...
gcc 4.7.3
gdb (GDB) 7.5.91.20130417

greetings

[MortenMacFly]

Since we are using wx3.0 propgrid; we should NOT have the one in SDK in the search list.

That is true... and applied in trunk. Thank you!

[Uskok]

Try to disable CC, it corrupted something very badly.

This problem happens during startup, I doubt it is related to CC...

Edit: It is not, I've tried with disabled CC.

I wrote suggestion because under Linux (RH 6.4, wx30, sources from trunk) I had strange behavior of CodeBlocks. I was able to open project and after start compile only the messages from first file was omitted and the CB stops to response.  With disabled CC compilation process was OK.

[oBFusCATed]

Uskok: You are experiencing the same problem. But because the bug is a race condition or something like that is not 100% reproducible.

BlueHazzard: Can you post the versions of kernel, gtk+, glibc, glib?

[BlueHazzard]

libgtk 3.6.4-0ubuntu8
glibc 2.17
glib 2.36
kernel 3.8.0 (wow quite old oO)

greetings

[oBFusCATed]

BlueHazzard:
Could you try to rebuild wx30 with the --enable-debug configure option and try again to debug the minimal sample.
I've just rebuild my wx30 without using this option and C::B starts inside C::B without problems.
I can debug the minimal sample project, too.

[BlueHazzard]

with --enable-debug it is a different behaviour:
1) if i run it with gdb (with a break point on wxExecute) it works, and the process exits without error
1.1) if i run it with gdb step by step it blocks at utilsunix.cpp:853 in

Code Select Expand

return BlockUntilChildExit(execData);
and i get a zombie gcc process
1.2) if i run it with gdb step by step without wxEXEC_NOEVENTS it blocks at utilsunix.cpp:862 and i get a zombie gcc process

in both cases i had to step until this line. If i only run with the debugger there was no error...

3.1) if i run it without debugger with wxEXEC_NOEVENTS i get a zombie gcc process
3.2) if i run it without debugger without wxEXEC_NOEVENTS the process ends without error

greetings

[oBFusCATed]

Thank you for your experiments. One question what do you mean by gdb: standalone gdb in terminal or gdb run by C::B's debugger plugin?

[BlueHazzard]

gdb in C::B plugin...
but there were no errors on the c::b site. The log was ok and also the application responded...
greetings