logging problems if pathname contains non utf8 characters

[mmeltner]

Hello,

gschem crashes with
(process:14649): Gtk-CRITICAL (recursed) **: gtk_text_buffer_emit_insert: assertion `g_utf8_validate (text, len, NULL)' failed
aborting...

when I have a UTF8 cheracter in the definition of additional libraries like:
(component-library "${HOME}/develop/existenzgründung/noise-source/pcb/gschem-sym")

This german umlaut ü is the culprit.

Version is: geda-gschem-20070626

The backtrace follows:

#0 0x00002b591f56111b in raise () from /lib/libc.so.6
#1 0x00002b591f562600 in abort () from /lib/libc.so.6
#2 0x00002b591eac9a98 in g_logv () from /usr/lib/libglib-2.0.so.0
#3 0x00002b591eac9b23 in g_log () from /usr/lib/libglib-2.0.so.0
#4 0x000000000043d49d in log_message (log=0x7492a0,
    message=0x68ab60 "New page created [/home/chief/develop/existenzgründung/noise-source/pcb/noise-source/untitled_2.sch]\n") at x_log.c:166
#5 0x00002b591eac9801 in g_logv () from /usr/lib/libglib-2.0.so.0
#6 0x00002b591eac9b23 in g_log () from /usr/lib/libglib-2.0.so.0
#7 0x00002b591e74a25e in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#8 0x00002b591e75eaea in signal_emit_unlocked_R ()
   from /usr/lib/libgobject-2.0.so.0
#9 0x00002b591e76049f in g_signal_emit_valist ()
   from /usr/lib/libgobject-2.0.so.0
#10 0x00002b591e760963 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#11 0x00002b591ecf0dcb in gtk_real_button_released ()
   from /usr/lib/libgtk-x11-2.0.so.0
#12 0x00002b591e74a25e in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#13 0x00002b591e75e7af in signal_emit_unlocked_R ()
   from /usr/lib/libgobject-2.0.so.0
#14 0x00002b591e76049f in g_signal_emit_valist ()
   from /usr/lib/libgobject-2.0.so.0
#15 0x00002b591e760963 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
---Type <return> to continue, or q <return> to quit---
#16 0x00002b591ecf0ea6 in gtk_button_button_release ()
   from /usr/lib/libgtk-x11-2.0.so.0
#17 0x00002b591ee03ab3 in _gtk_marshal_BOOLEAN__BOXED ()
   from /usr/lib/libgtk-x11-2.0.so.0
#18 0x00002b591e74a25e in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#19 0x00002b591e75eead in signal_emit_unlocked_R ()
   from /usr/lib/libgobject-2.0.so.0
#20 0x00002b591e760266 in g_signal_emit_valist ()
   from /usr/lib/libgobject-2.0.so.0
#21 0x00002b591e760963 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#22 0x00002b591ef7c045 in gtk_widget_event_internal ()
   from /usr/lib/libgtk-x11-2.0.so.0
#23 0x00002b591edfb37f in gtk_propagate_event ()
   from /usr/lib/libgtk-x11-2.0.so.0
#24 0x00002b591edfcd93 in gtk_main_do_event ()
   from /usr/lib/libgtk-x11-2.0.so.0
#25 0x00002b591df71fdc in gdk_event_dispatch ()
   from /usr/lib/libgdk-x11-2.0.so.0
#26 0x00002b591eac22bf in g_main_context_dispatch ()
   from /usr/lib/libglib-2.0.so.0
#27 0x00002b591eac2b05 in g_main_context_iterate ()
   from /usr/lib/libglib-2.0.so.0
#28 0x00002b591eac2e05 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
---Type <return> to continue, or q <return> to quit---
#29 0x00002b591edfc662 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#30 0x0000000000416d06 in main_prog (closure=<value optimized out>, argc=1,
    argv=0x7fff8dda4fd8) at gschem.c:282
#31 0x00002b591d0e6101 in scm_boot_guile () from /usr/lib/libguile.so.12
#32 0x0000000000416911 in main (argc=1, argv=0x7fff8dda4fd8) at gschem.c:307
(gdb)
(gdb)

[Peter TB Brett (peter-b)]

When you've defined such a library, what steps do you have to take to make gschem crash? Does it happen when you're doing a specific thing?

[Peter TB Brett (peter-b)]

I'm having difficulty reproducing this bug:

- I created a library with a ü in the name
- gschem worked fine
- I tried running from a directory called "hähnchen" (this is where your segfault appears to have _actually_ come from) and gschem created the untitled file just fine.

Works for me -- I need better steps to reproduce.

[sf-robot (sf-robot-users)]

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

[Peter Clifton (pcjc2)]

This looks like an old bug, where the file-system is not actually stored in UTF8 encoding. The log window (used to)? crash with an utf8 validation assertion when the log message printed out what file had been opened.

The fix (still required for correct log output) is to convert from the file-sytem encoding to UTF8 before sending the log message.