void-packages icon indicating copy to clipboard operation
void-packages copied to clipboard

LibreCAD crashes when loading self-created or modified DXF files

Open twingofan opened this issue 6 months ago • 2 comments

Is this a new report?

Yes

System Info

Void 6.12.33_1 x86_64 AuthenticAMD uptodate FFFFFFFF

Package(s) Affected

LibreCAD-2.2.1.1_1

Does a report exist for this bug with the project's home (upstream) and/or another distro?

No response

Expected behaviour

LibreCAD should be able to load its own DXFs. Flatpak v2.2.1.1 and AppImage v2.2.1.1 versions, as well as FreeCAD 1.0.1_2, load the same files without error.

Actual behaviour

Void's version of LibreCAD consistently crashes when loading DXFs created or modified with LibreCAD. This includes files from the Flatpak and AppImage versions. DXFs created by other software seem to work, or at least couldn't find any files online that caused crashing. No error messages, just [1] 7676 segmentation fault librecad

Steps to reproduce

  1. Launch LibreCAD and attempt to open any DXF that has been created or modified with LibreCAD 1a. Saving a blank DXF (specific version seems to be unimportant) and loading it is enough to trigger the issue
  2. Instant crash.

twingofan avatar Jun 19 '25 02:06 twingofan

looks like they have a couple open issues about dxf

https://github.com/LibreCAD/LibreCAD/issues/2193

https://github.com/LibreCAD/LibreCAD/issues/2137

does 2.2.0.1 work ?

zlice avatar Jun 19 '25 17:06 zlice

2.2.0.1 Void https://github.com/void-linux/void-packages/commit/4ea3dce447ff91d5757b498cbc1bbcaeaba804e6 and AppImage work correctly, as well as the 2.2.2_alpha1 AppImage suggested in those linked issues.

Noticed that LibreCAD's only unique dependency on my system is muparser, which recently had an update to 2.3.5 https://github.com/void-linux/void-packages/pull/55715. I built the ancient muparser 2.2.6.1 template from 2018 https://github.com/void-linux/void-packages/commit/cfcb2dc2a13fae022f159e01b186c08eb7efa5df and that stopped LibreCAD 2.2.1.1 from crashing - so it looks like a problem between specifically LibreCAD 2.2.1.1 and muparser 2.3.5 (neither current LibreCAD + old muparser or old LibreCAD + current muparser crash on DXF load).

twingofan avatar Jun 19 '25 21:06 twingofan

Sorry about that, I did some testing of libreCAD with the update, but that probably didn't exercise the crashing code path.

@twingofan Can you share a DXF that is making it crash on importing ?

I only saw this by chance, you should have @'ed me, I could have had a look at the issue sooner.

vincele avatar Aug 29 '25 17:08 vincele

@classabbyamp any tips on how to proceed ? revert muparser until a fix is found ?

vincele avatar Sep 09 '25 20:09 vincele

Apologies for not responding sooner, I've been away from my computer for a while. Here's a blank DXF that crashes on open and a complex DXF that doesn't crash initially - but zooming the viewport and saving (which significantly reduces the size of the file?) will make it crash when reopened. Thanks for taking a look and hope this is still useful to you.

dxfs.zip

twingofan avatar Sep 10 '25 01:09 twingofan

both of those above librecad issues are still open so i dont think it's fixed. probably better chiming in there if you haven't

zlice avatar Sep 10 '25 01:09 zlice

I opened both .dxf files from the zip succesfully with my local build of librecad (from when I tested the muparser update):

Version: 2.2.1.1
Compiler: GNU GCC 14.2.1
Compiled on: Jun 10 2025
Qt Version: 5.15.11
Boost Version: 1.83.0
System: Void Linux

And my local librecad is linked with musl & muparser-2.3.5:

$ ls -l $(ldd `which librecad` | awk '/muparser|libc/{print $3}')
lrwxrwxrwx 1 root root 18 May 26 00:47 /lib/ld-musl-x86_64.so.1 -> /usr/lib64/libc.so
lrwxrwxrwx 1 root root 20 Jun 10 16:14 /lib/libmuparser.so.2 -> libmuparser.so.2.3.5

The blank.dxf I added a few lines, saved as another file, closed it, re-opened that newly created copy, still no crash.

In the other one I see a potentiometer or joystick, can zoom in and out. If I save as another name, close, then re-open the new copy (which is about half the size of the original), it still opens and don't crash.

$ ls -nhl *.dxf
-rw-r--r-- 1 1000 1000  17K Sep 10 22:51 blank+star.dxf
-rw-r--r-- 1 1000 1000  16K Sep 10 03:08 blank.dxf
-rw-r--r-- 1 1000 1000 689K Sep 10 23:15 em14c0d-e24-l064s_back-copy.dxf
-rw-r--r-- 1 1000 1000 1.2M Jun  1 18:59 em14c0d-e24-l064s_back.dxf

Maybe it only crashes on glibc ?

vincele avatar Sep 10 '25 21:09 vincele

With the new release:

Version: 2.2.1.2
Compiler: GNU GCC 14.2.1
Compiled on: Sep 10 2025
Qt Version: 5.15.11
Boost Version: 1.89.0
System: Void Linux

It's working OK for me, I did all the same tests as with 2.2.1.1, so sorry, but I cannot reproduce the crash at all (cannot say the same about FreeCAD, at all)...

It would be interesting to have a backtrace of the crash from a build with debug infos...

BTW, you have a few 2.2.2 version that I don't think exist, are those typos ? 2.2.2_alpha1 and 2.2.2.1 or did I miss something ?

vincele avatar Sep 10 '25 21:09 vincele

2.2.2_alpha1 was a test build from one of the linked upstream issues (https://github.com/LibreCAD/LibreCAD/issues/2193#issuecomment-2975195015), 2.2.2.1 was a typo and should be 2.2.1.1, sorry about that. I tested in a fresh VM (glibc, my main system is glibc as well) just to rule out any configuration/hardware problems and was still able to reliably trigger segfaults with blank file -> save -> reload, see attached video. Also tried the two test files with the same results. I'll see if I can replicate on a musl VM next, maybe that's the issue.

https://github.com/user-attachments/assets/fd4febe0-fda5-43cb-962d-3829df60b27a

twingofan avatar Sep 11 '25 01:09 twingofan

Yes, I think a test with a musl VM will be nice to pinpoint or rule out glibc/musl as the culprit.

vincele avatar Sep 11 '25 16:09 vincele