Hi Jens Am 17.08.2013 um 07:53 schrieb Jens Georg <mail jensge org>:
[ Wonders of unix signals ]
:)
Seriously? Removing the debug statement is fixing the issue for you?yes, it fixes one issue and since adding the fix to my code I haven't run into any other issue yet. This one is definitely a bug, you're not supposed to use non async-signal-safe stuff in a signal handler. As g_debug() calls malloc(), which is not async-signal-safe, we MUST remove the log statement from the signal handler.Shouldn't this be solvable by using g_unix_signal_add* if you want to keep the debug messages?
That would be one option. Another one would be using glib function g_spawn_async_with_pipes() instead of directly using fork() and handling signals. But for that Tracker would need an additional binary (e.g. tracker-extract-pdf) that we can spawn with g_spawn_async_with_pipes(). Here's an example for using g_spawn_async_with_pipes(): <http://blog.borovsak.si/2009/07/spawning-processes-using-glib.html>
Though I have a faint memory of only certain signals being valid to use with this, but can't find that currently.
Looks like. <https://developer.gnome.org/glib/2.30/glib-UNIX-specific-utilities-and-integration.html#g-unix-signal-source-new> "Currently only SIGHUP, SIGINT, and SIGTERM can be monitored." Damn. -r -- Ralph Böhme <rb netafp com> Netatalk Developer | Support | Services Curslacker Deich 254, 21039 Hamburg, Germany http://www.netafp.com/
Attachment:
smime.p7s
Description: S/MIME cryptographic signature