code::blocks hangs at startup

[killerbot]

2 days ago, since a very long time, I did a fresh build of CB on linux, in Tumbleweed.
Build goes fine, but launching fails. With a similar problem as mentioned above, and the 'renaming' the 3 wxSmith zip files.
Probably when starting a build by excluding these plug-in(s) things would have been ok too.

Code

sudo mv /usr/local/share/codeblocks/wxSmithAui.zip /usr/local/share/codeblocks/wxSmithAui.old
sudo mv /usr/local/share/codeblocks/wxsmithcontribitems.zip /usr/local/share/codeblocks/wxsmithcontribitems.old
sudo mv /usr/local/share/codeblocks/wxsmith.zip /usr/local/share/codeblocks/wxsmith.old

Conclusion: this problem is not solved yet, did anyone in the meantime had a look at it ?



for reference, I stumbled also upon: https://bbs.archlinux.org/viewtopic.php?id=308575

[stahta01]

2 days ago, since a very long time, I did a fresh build of CB on linux, in Tumbleweed.
Build goes fine, but launching fails. With a similar problem as mentioned above, and the 'renaming' the 3 wxSmith zip files.
Probably when starting a build by excluding these plug-in(s) things would have been ok too.

Code

sudo mv /usr/local/share/codeblocks/wxSmithAui.zip /usr/local/share/codeblocks/wxSmithAui.old
sudo mv /usr/local/share/codeblocks/wxsmithcontribitems.zip /usr/local/share/codeblocks/wxsmithcontribitems.old
sudo mv /usr/local/share/codeblocks/wxsmith.zip /usr/local/share/codeblocks/wxsmith.old

Conclusion: this problem is not solved yet, did anyone in the meantime had a look at it ?



for reference, I stumbled also upon: https://bbs.archlinux.org/viewtopic.php?id=308575

What wxWidget version is being used?
My wild guess is the png images; I checked one image file and if not wxCHECK_VERSION(3, 1, 6) then png images are used.
Edit: The single source file (wxsitemeditor.cpp) I checked was the only one that used the svg images if 3.1.6 or newer.

Tim S.

[Miguel Gimenez]

Works OK on Ubuntu 22.04 with wxWidgets 3.2.6, I cannot check on other Linux. wxSmith uses some initialization tricks that may be non-portable.

This ticket reports that downgrading gdk-pixbuf2 from 2.44.2-1 to 2.42.12-2 fixes the problem.

[Miguel Gimenez]

On 2.43 gdk-pixbuf deprecated the XPM api and disabled XPM loader by default, see release notes.

wxSmith defines a XPM in wxSmith.cpp:50 and uses it during plugin attachment in wxSmith.cpp:211; Probably changing this XPM to a PNG or SVG fixes the issue.

[Miguel Gimenez]

Replaced XPM with PNG in OnAttach(), see r13773, this may fix the issue (untested).

There are more XPM bitmaps in other parts.

[killerbot]

the wxwidgets I used is : 3.2.8

I updated with your latest commit, the problem is still there.

fyi: my gdk-pixbug version is 2.44.4

[Miguel Gimenez]

Can you put a breakpoint in OnAttach() and check where it hangs?

[stahta01]

Patch for my wild guess at the cause, could be multiple causes since wxSmith was written for old wxWidgets version. Edit: My wild guess is that the png files are old enough to break something.

Deleted outdated patch code

Tim S.

[killerbot]

I applied this, but no luck, problem still present.

[killerbot]

#0  0x00007ffff4f1e80d in syscall () at /lib64/libc.so.6
#1  0x00007ffff4747e95 in std::sys::sync::condvar::futex::Condvar::wait () at /lib64/libglycin-2.so.0
#2  0x00007ffff46cb1bb in parking::Inner::park () at /lib64/libglycin-2.so.0
#3  0x00007ffff45fd656 in gly_loader_load () at /lib64/libglycin-2.so.0
#4  0x00007ffff712325e in () at /lib64/libgdk_pixbuf-2.0.so.0
#5  0x00007ffff7123637 in () at /lib64/libgdk_pixbuf-2.0.so.0
#6  0x00007ffff7113158 in gdk_pixbuf_new_from_file () at /lib64/libgdk_pixbuf-2.0.so.0
#7  0x00007ffff6b7d3b0 in wxBitmap::LoadFile(wxString const&, wxBitmapType) () at /lib64/libwx_gtk3u_core-suse-nostl.so.16.0.0
#8  0x00007fffc8ebe80f in wxsRegisterItem<wxsAnimationCtrl>::wxsRegisterItem(wxString, wxsItemType, wxString, long, bool) ()
    at /usr/local/lib/libwxsmithlib.so.0
#9  0x00007fffc8d6bacf in _GLOBAL__sub_I_wxsanimationctrl.cpp () at /usr/local/lib/libwxsmithlib.so.0


not sure if really usable, can not reproduce, ran in gdb, when it hang : ctrl-c and then bt.
but most of the other times I get something else ...

[Miguel Gimenez]

not sure if really usable

It is very helpful indeed.

IMHO the problem is wxSmith uses global objects to register items:

Code

namespace
{
    wxsRegisterItem<wxsAnimationCtrl> Reg(_T("AnimationCtrl"),wxsTWidget,_T("Standard"),370);

The constructor of wxsRegisterItem (in wxsitemfactory.h:200) calls wxBitmap::LoadFile(), but this call will happen before the image handlers have been initialized because global objects are constructed before program starts.

Code

            wxString DataPath = ConfigManager::GetDataFolder() + _T("/images/wxsmith/");
            Info.Icon32.LoadFile(DataPath+Info.ClassName+_T("32.png"),wxBITMAP_TYPE_PNG);
            Info.Icon16.LoadFile(DataPath+Info.ClassName+_T("16.png"),wxBITMAP_TYPE_PNG);

One possible solution would be delay loading the icons, i.e. load them the first time they are needed.

[Miguel Gimenez]

I have just commited r13775 implementing delay-load of most images. This commit will make easier changing to SVG in the near future.

wxsresourcetree must still be modified before checking if C::B still hangs at startup.

[killerbot]

I will test later today

[Miguel Gimenez]

The change is not finished, wxsresourcetree must be modified.

[killerbot]

I reverted the patch that was posted here above yesterday,and used your latest commit.

CB now starts up for me without problems (or at least not directly visible to me ;-) )