Hey there! Thanks for helping Mudlet improve. 🌟

Test versions

You can directly test the changes here:

• linux: https://make.mudlet.org/snapshots/566682/Mudlet-4.13.1-testing-pr4774-9911756b-linux-x64.AppImage.tar
• osx: https://make.mudlet.org/snapshots/9a239d/Mudlet-4.13.1-testing-pr4774-9911756b.dmg
• windows: https://make.mudlet.org/snapshots/a906a9/Mudlet-4.13.1-testing-pr4774-9911756b-windows.zip

No need to install anything - just unzip and run.
Let us know if it works well, and if it doesn't, please give details.

Did not seem to actually have an effect on the binary size - suspicious. @Kebap does it work better for your crash?

Did not seem to actually have an effect on the binary size - suspicious. @Kebap does it work better for your crash?

Not at all

Did not seem to actually have an effect on the binary size - suspicious.

Agreed. However I find that I cannot run the AppImage - it looks like it is using a too new libstc++ - and I thought the AppImage recommendation was to always build against the oldest system libraries that one wanted an Application to run on:

stephen@Ripley:~/Downloads$ file ./squashfs-root/mudlet
./squashfs-root/mudlet: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=8aaf6011c290e70e3405d95396935f829067776b, with debug_info, not stripped
stephen@Ripley:~/Downloads$ strings /usr/lib/x86_64-linux-gnu/libstdc++.so.6 | grep GLIBCXX
GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
GLIBCXX_3.4.4
GLIBCXX_3.4.5
GLIBCXX_3.4.6
GLIBCXX_3.4.7
GLIBCXX_3.4.8
GLIBCXX_3.4.9
GLIBCXX_3.4.10
GLIBCXX_3.4.11
GLIBCXX_3.4.12
GLIBCXX_3.4.13
GLIBCXX_3.4.14
GLIBCXX_3.4.15
GLIBCXX_3.4.16
GLIBCXX_3.4.17
GLIBCXX_3.4.18
GLIBCXX_3.4.19
GLIBCXX_3.4.20
GLIBCXX_3.4.21
GLIBCXX_3.4.22
GLIBCXX_3.4.23
GLIBCXX_3.4.24
GLIBCXX_3.4.25
GLIBCXX_DEBUG_MESSAGE_LENGTH
stephen@Ripley:~/Downloads$ ldd ./squashfs-root/mudlet | grep -i -v "squash"
        linux-vdso.so.1 (0x00007ffefa1f6000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f587735b000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f58753a4000)
        libGL.so.1 => /usr/lib/x86_64-linux-gnu/libGL.so.1 (0x00007f5875310000)
        libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f587518c000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f5875007000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f5874fed000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f5874e2c000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f5874e27000)
        libglib-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007f58748b1000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f5878a01000)
        libGLX.so.0 => /usr/lib/x86_64-linux-gnu/libGLX.so.0 (0x00007f5871870000)
        libGLdispatch.so.0 => /usr/lib/x86_64-linux-gnu/libGLdispatch.so.0 (0x00007f58717b1000)
        libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x00007f5870dcf000)
        libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f5870a82000)
        libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007f5870870000)
        libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f5870846000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f586ff23000)
        libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f586fd02000)
        libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f586fafe000)
        libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f586f8f8000)
        libbsd.so.0 => /usr/lib/x86_64-linux-gnu/libbsd.so.0 (0x00007f586ea72000)
        libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007f586ea4f000)
stephen@Ripley:~/Downloads$ ./Mudlet-4.10.1-testing-pr4774-2aedb911.AppImage 
./Mudlet-4.10.1-testing-pr4774-2aedb911.AppImage: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by ./Mudlet-4.10.1-testing-pr4774-2aedb911.AppImage)
stephen@Ripley:~/Downloads$

See #4766 for that problem.

For temporary testing of the AppImage and other test builds could we temporarily have an undocumented Lua API function that will provoke a crash - say by dereferencing a nullptr or by causing a div/0 FPE - so that we can evaluation whether useful debug information is provided in a controlled manner?

☠️ Obviously that should be reverted before this PR is merged... ☠️

We can yeah.

Do you know have ideas on how to solve the original problem?

Motivation for adding to Mudlet

So running off-the-shelf builds in Qt Creator will give useful stacktrace information.

I thought it was to give useful stacktrace information outside of Creator... 😆

Nice that worked, it's a 106mb now.

Can't use it by default but I wonder if we can make a bot to ask us to make a debug build on demand 🤔

Can't use it by default but I wonder if we can make a bot to ask us to make a debug build on demand 🤔

How about just on non-release builds (including the debug info on PTB builds is going to help when they break I expect)?

FTR - at least in qmake builds one can also add CONFIG+=separate_debug_info and that extracts the debug symbols to a separate .debug extension file which gdb and related tools know to associate with the executable. Basically it causes qmake to do this at the end of the build:

objcopy --only-keep-debug mudlet mudlet.debug
objcopy --strip-debug mudlet
objcopy --add-gnu-debuglink=mudlet.debug mudlet
chmod -x mudlet.debug

We can do that ourselves - and in fact we'd have to if we want to rename the executable after the build (which we do on MacOs and Windows IIRC)...

How about just on non-release builds (including the debug info on PTB builds is going to help when they break I expect)?

Still too huge to be used, the amount of times we've actually needed them has been really tiny - can't make everyone pay the price of downloading 2x sized Mudlet 100% of the time, I think.

Separate debug info that we could download on-demand sounds interesting!

Separate debug info that we could download on-demand sounds interesting!

If you can arrange the infrastructure to make sure the matching .debug file is made available, then sure - but it will make things more complex there - I do not kniow if that can be integrated into a mythical crash handler when we get that sorted but it is certainly something to investigate... 😮

Technically, I believe, the main advantage seen in a separate debug file is held to be the quicker loading/execution startup time - rather than the smaller download.

What's the status of this PR now? Is it that we can produce the debug information but that it makes the executables bigger than we'd like - or that we don't want to include the separate .debug file that will be wanted if we do separate it out?

I think for players it would be best if we can point them to a complete version to try with debug symbols included.
Adding and including separate debug files seems like extra hurdles to jump in a new way that is not easy to do.
Better stick to what players know already: Download and use Mudlet, just like PTB and DEV versions offered.

Now talking about developers, that way may make more sense.
Then again, most can probably compile by themselves (not me)

I wonder if we can make a bot to ask us to make a debug build on demand

For release versions? For PTB? For each PR?

What's the status of this PR now?

I think it was testing the process, not to be included at all, but I am unsure about the way forward as well

TBH I think it would be worthwhile to have the debug symbols in the PTBs and testing PRs - for the PTBs there is - I think - a slight benefit to have the debug symbols in a separate file as that should load faster (and on Windows I expect that shows the most as there is less for an AV tool to churn through). However I am in two minds as to whether release versions should be shipped with debug information because I think Qt uses gccs -02 rather than -03 when -g is also involved - if I understand things correctly it is not possible to use every possible optimisation when debugging information is also wanted.

That being the case, the use of the changes currently proposed here must be gated in some way against the build type.

#4774 (comment) Are you OK with a 2x Mudlet size on PTB releases all the time?

#4774 (comment) Are you OK with a 2x Mudlet size on PTB releases all the time?

I think we can justify it on the grounds of "we now include the debug symbols in these nightly test builds so ifwhen they break we have a better chance at working out what went wrong!"

Though, to be fair, my bit-hose is a fat one (100Mbps) so download times are not an issue for me...

not an issue for me...

shouldn't be the measuring stick for this decision.

We want diverse players using PTB all day every day, not only when they feel the need to test something, so they do test all the time, and reporting more bugs quicker. They should also update often, which makes less size better.
Again, once a player reports a bug, and we could not immediately pinpoint the exact cause already, then it is still ample time to direct her to a version with additional debug files (external or internal as well) to download and test explicitly.
Until that situation arises, we must not always double the size for all, just because it may sometimes help a few. It's just not worth it.

Until that situation arises, we must not always double the size for all, just because it may sometimes help a few. It's just not worth it.

Well, can we rejig the build platforms so that they do produce the debug symbols as a separate file and then produce either two installers from the same materials - one with and one without the debug file - or arrange for the matching debug file to be downloaded by the executable upon demand - even if that is an option on the help menu. i am not sure quite how that would be done as the particular file needed would have to be baked into the executable.

In summary I would expect the builds to be:

• PR/Testing builds - GCC options -O0 -g - debug symbols in the executable.
• PT Builds - GCC options -O2 -g - debug symbols in a separate file either distributed with the package {not wanted by @Kebap and not really liked by @vadi2} or separately in some manner yet to be deduced.
• Release builds - GCC options -O3 - no debug symbols.

So the issue to be resolve is, unless I am mistaken, is: how to make the PTB debug symbol file available to those that want it - not forgetting that they will need to persist much longer on our servers than the actual PTB installer that are only retained for a couple of weeks. This is because the downloader may not choose to update - or might well save the download locally as a reference to how things were on a particular date in the past and reinstall them to test something or work around an unfixed bug introduced later on.

I think it's a reasonable breakdown. We're aligned on the fact that we don't want big builds all the time, and on the fact that whenever they're needed, they can be obtained.

Unless someone can step up to building it, we don't have the bandwidth to build the infrastructure necessary. But we do know how to do the builds - as this PR shows, it's just 2 simple lines. So we can just remember this method - and document in the code on how to do it - and whenever we need a build with debug symbols, we can just make a quick PR for it.

Converted it to comments for now as we don't have a good solution for managing it, but still want to keep this knowledge.