Inkscape (and some other GTK apps) crashing when using Spanish locale format

Software Ports
1

As the title says. I was trying to port Nicotine+ (a Soulseek client written on GTK) and on my first tests the app would not start. Instead, I got a crash window (on GTK, at least). I then tried Inkscape, and while the welcome screen works, as soon as you try to open a file or create a new one the program crashes. Both crashes (Inkscape and Nicotine+) seem to be related to GTK theme parsing.

GIMP and Iceweasel (Firefox) work fine.

This is the terminal output when Inkscape crashes. I’ll leave Nicotine+ out of the picture for now as it is not ported yet and I’m suspicious both crashes are related.

** (org.inkscape.Inkscape:1680): CRITICAL **: 15:04:27.338: CSSProviderError::load_from_path(): failed to load '/packages/inkscape-1.3.2-2/.self/data/inkscape/ui/style.css'
(style.css:84:14Junk at end of value for opacity)

** (org.inkscape.Inkscape:1680): CRITICAL **: 15:04:27.353: CSSProviderError::load_from_path(): failed to load '/packages/inkscape-1.3.2-2/.self/data/inkscape/ui/Adwaita.css'
(Adwaita.css:47:31Expected closing ')')

** (org.inkscape.Inkscape:1680): CRITICAL **: 15:04:29.000: 
unhandled exception (type Glib::Error) in signal handler:
domain: g-variant-parse-error-quark
code  : 5
what  : Detailed action name 'app.transform-scale(2.0)' has invalid format: 1-2:invalid character in number


(org.inkscape.Inkscape:1680): Gtk-CRITICAL **: 15:04:29.006: gtk_widget_get_allocated_size: assertion 'GTK_IS_WIDGET (widget)' failed

(org.inkscape.Inkscape:1680): Gtk-CRITICAL **: 15:04:29.006: gtk_widget_size_allocate_with_baseline: assertion 'GTK_IS_WIDGET (widget)' failed

Any ideas about what should I try or where should I start investigating?

Thanks in advance

2 Likes
2

I suggest updating Haiku’s GTK recipe and gtk3-classic patches, maybe it will be solved by updating the GTK version:

@3dEyes , do you have any solution?

3

Do you have a crash report?

4

I’ll report back with a crash report soon, but with the help of Nicotine+'s main developer I did some tests and:

  • Fresh VM, latest nightly: Nicotine+ crashes.
  • Fresh VM, Beta 5: Nicotine+ runs as expected and I can download files normally. Inkscape seems to be working perfectly here as well.

I forgot to test Inkscape on a fresh VM with the latest nightly (I will ASAP), but the problem seems to be on Haiku’s code itself. The other thing I can think of is some kind of dependency missing on the nightlies but included on Beta 5, but it seems more unlikely.

1 Like
5

So I was wrong: it’s the format locale. I’m using Spanish, where numbers are 1.234,56, while in English they are (1,234.56). As soon as I select the english locale format and restart, Nicotine+ works. Inkscape was throwing this line:

what  : Detailed action name 'app.transform-scale(2.0)' has invalid format: 1-2:invalid character in number

That 2.0 is not being “treated” right. On a given css file, you have a lot of these cases where a floating point number is used.

To reproduce, simply change the format locale to Spanish, restart Haiku and try to start Inkscape.

EDIT: I changed the post title so it reflects the actual issue.

6

I’ve had such issues before on Haiku, usually when some library incorrectly uses posix “locale aware” parsing functions, when it really wants a predictable parser

2 Likes
7

I’ll try to investigate further. Nicotine+'s main dev (Mat) is been helping a lot, already making patches to fix issues under Haiku and testing this issue. He could reproduce this on nightly but not on Beta 5. His latest findings show that fontconfig is also affected by this bug. You can see his progress on Trying to port Nicotine+ to Haiku (app crashes on start) · Issue #3385 · nicotine-plus/nicotine-plus · GitHub

I’m keen on filing a bug report but I was expecting to at least know which library or component is at fault. Or should I file one with the information we have at the moment?

8

The relevant changes are going to be in the C library. Just file the ticket with the info you have now. :slight_smile:
(and ideally the recipe to test this with)

9

Mat just did the work for me:

hrev58793 is the last nightly build that worked, hrev58799 breaks.
haiku/haiku@7174197 looks like the culprit.
glib’s strtod implementation (used in GTK 3’s CSS parser): glib/glib/gstrfuncs.c at 39b5613e739c90ea9386ebdcb18916fbf23f5688 · GNOME/glib · GitHub
fontconfig’s strtod implementation: Making sure you're not a bot!

Filing a bug report now.
EDIT: bug report

1 Like