glib2.0 crashes when applications are started with chrt

Bug #453898 reported by pablomme
16
This bug affects 3 people
Affects Status Importance Assigned to Milestone
GLib
Expired
Medium
glib2.0 (Ubuntu)
Triaged
Low
Unassigned

Bug Description

Binary package hint: ardour

I'm running the latest karmic as of this writing (17-Oct-2009), and I'm using the 2.6.31-9-rt kernel.

I launch ardour using the command "chrt 69 ardour2" to ensure it gets enough attention from the system. This worked flawlessly in Jaunty (with a custom-compiled kernel, though), but in Karmic I get:

---
$ chrt 69 ardour2
WARNING: Your system has a limit for maximum amount of locked memory!
         This might cause Ardour to run out of memory before your system runs
         out of memory. You can view the memory limit with 'ulimit -l', and it
         is normally controlled by /etc/security/limits.conf

Ardour/GTK 2.8.2
   (built using 5396 and GCC version 4.4.1)
Copyright (C) 1999-2008 Paul Davis
Some portions Copyright (C) Steve Harris, Ari Johnson, Brett Viren, Joel Baker

Ardour comes with ABSOLUTELY NO WARRANTY
not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
This is free software, and you are welcome to redistribute it
under certain conditions; see the source for copying conditions.
loading default ui configuration file /etc/ardour2/ardour2_ui_default.conf
loading user ui configuration file /home/pablo/.ardour2/ardour2_ui.conf
Loading ui configuration file /etc/ardour2/ardour2_ui_dark.rc
theme_init() called from internal clearlooks engine
ardour: [INFO]: Ardour will be limited to 1024 open files
loading system configuration file /etc/ardour2/ardour_system.rc
loading user configuration file /home/pablo/.ardour2/ardour.rc
ardour: [INFO]: No H/W specific optimizations in use

GThread-ERROR **: file /build/buildd/glib2.0-2.22.2/gthread/gthread-posix.c: line 348 (g_thread_create_posix_impl): error 'Invalid argument' during 'pthread_attr_setschedparam (&attr, &sched)'
aborting...
Aborted (core dumped)
---

This doesn't happen if I execute "ardour2" and then "chrt -p 69 $(pidof ardour-2.8.2)", so I guess that it is only at startup that Ardour's scheduling policy/priority is checked by glib.

I guess the problem is really in glib, so I'll add it to the package list. I will recheck with the non-rt kernel to see what happens there.

For the record, I'm also running jackd at a priority of 75, hydrogen (compiled from svn) at a priority of 69, and have increased the priority of the soundcard and rtc0 interrupts to 85 and 98, respectively [all of these with policy SCHED_RR].

ProblemType: Bug
Architecture: amd64
Date: Sat Oct 17 13:07:06 2009
DistroRelease: Ubuntu 9.10
Package: ardour 1:2.8.2-0ubuntu1
ProcEnviron:
 PATH=(custom, user)
 LANG=en_GB.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-9.152-rt
SourcePackage: ardour
Uname: Linux 2.6.31-9-rt x86_64
XsessionErrors:
 (gnome-settings-daemon:2810): GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed
 (gnome-settings-daemon:2810): GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed
 (polkit-gnome-authentication-agent-1:2928): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed
 (nautilus:2916): Eel-CRITICAL **: eel_preferences_get_boolean: assertion `preferences_is_initialized ()' failed
 (gnome-panel:2913): Gdk-WARNING **: /build/buildd/gtk+2.0-2.18.2/gdk/x11/gdkdrawable-x11.c:952 drawable is not a pixmap or window

Revision history for this message
pablomme (pablomme) wrote :
pablomme (pablomme)
affects: ardour (Ubuntu) → glib2.0 (Ubuntu)
Revision history for this message
pablomme (pablomme) wrote :

Checked that it happens also with kernel 2.6.31-14-generic.

Also, I've found out that this happens with many other GTK applications, presumably those which are threaded (nautilus, rhythmbox, totem, etc), and non-threaded ones (gcacl-tool, same-gnome, gnome-terminal, etc) are not affected.

So this has nothing to do with ardour at all. I've reassigned the bug to glib2.0. I'll update the description too.

Furthermore, it appears that the issue is with non-zero priorities. SCHED_IDLE|OTHER|BATCH do not accept non-zero priorities, so they work fine:
---
$ chrt -i 0 totem
$ chrt -o 0 totem
$ chrt -b 0 totem
---
however SCHED_FIFO|RR only accept non-zero priorites, and they fail to run:
---
$ chrt -f 50 totem

GThread-ERROR **: file /build/buildd/glib2.0-2.22.2/gthread/gthread-posix.c: line 348 (g_thread_create_posix_impl): error 'Invalid argument' during 'pthread_attr_setschedparam (&attr, &sched)'
aborting...
Aborted (core dumped)
$ chrt -r 50 totem

GThread-ERROR **: file /build/buildd/glib2.0-2.22.2/gthread/gthread-posix.c: line 348 (g_thread_create_posix_impl): error 'Invalid argument' during 'pthread_attr_setschedparam (&attr, &sched)'
aborting...
Aborted (core dumped)
---

Unrelated Launchpad question: how does one add (rather than replace) an affected package in a bug?

summary: - ardour crashes if launched with chrt
+ glib2.0 crashes when applications are started with chrt
Revision history for this message
Sebastien Bacher (seb128) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. Please try to obtain a backtrace following the instructions at http://wiki.ubuntu.com/DebuggingProgramCrash and upload the backtrace (as an attachment) to the bug report. This will greatly help us in tracking down your problem.

Changed in glib2.0 (Ubuntu):
importance: Undecided → Medium
status: New → Incomplete
Revision history for this message
pablomme (pablomme) wrote :

Backtrace for totem, run as "chrt gdb totem" (since "gdb chrt totem" wouldn't work...):

---
(gdb) r
Starting program: /usr/bin/totem
[Thread debugging using libthread_db enabled]
[New Thread 0x2aaab99d0910 (LWP 4626)]

GThread-ERROR **: file /build/buildd/glib2.0-2.22.2/gthread/gthread-posix.c: line 348 (g_thread_create_posix_impl): error 'Invalid argument' during 'pthread_attr_setschedparam (&attr, &sched)'
aborting...

Program received signal SIGABRT, Aborted.
0x00002aaab0fba4b5 in raise () from /lib/libc.so.6
(gdb) bt
#0 0x00002aaab0fba4b5 in raise () from /lib/libc.so.6
#1 0x00002aaab0fbdf50 in abort () from /lib/libc.so.6
#2 0x00002aaaafceadfa in IA__g_logv (log_domain=<value optimised out>,
    log_level=<value optimised out>, format=<value optimised out>,
    args1=0x7fffffffdaa0) at /build/buildd/glib2.0-2.22.2/glib/gmessages.c:549
#3 0x00002aaaafceae93 in IA__g_log (
    log_domain=0x120e <Address 0x120e out of bounds>, log_level=4622,
    format=0x6 <Address 0x6 out of bounds>)
    at /build/buildd/glib2.0-2.22.2/glib/gmessages.c:569
#4 0x00002aaaaba2c482 in g_thread_create_posix_impl (
    thread_func=0x2aaaafd09af0 <g_thread_create_proxy>, arg=0xc06e80,
    stack_size=<value optimised out>, joinable=<value optimised out>, bound=0,
    priority=<value optimised out>, thread=0xc06eb0, error=0x7fffffffdc68)
    at /build/buildd/glib2.0-2.22.2/gthread/gthread-posix.c:348
#5 0x00002aaaafd091ce in IA__g_thread_create_full (
    func=<value optimised out>, data=<value optimised out>, stack_size=0,
    joinable=1, bound=0, priority=6, error=0x0)
    at /build/buildd/glib2.0-2.22.2/glib/gthread.c:663
#6 0x00002aaaba01a4d7 in ?? ()
   from /usr/lib/gstreamer-0.10/libgstxvimagesink.so
#7 0x00002aaaba01e8d8 in ?? ()
   from /usr/lib/gstreamer-0.10/libgstxvimagesink.so
#8 0x00002aaaab794bdc in gst_element_change_state ()
   from /usr/lib/libgstreamer-0.10.so.0
#9 0x00002aaaab797dea in ?? () from /usr/lib/libgstreamer-0.10.so.0
#10 0x00002aaab9e0d2a0 in ?? ()
   from /usr/lib/gstreamer-0.10/libgstautodetect.so
#11 0x00002aaaab794bdc in gst_element_change_state ()
   from /usr/lib/libgstreamer-0.10.so.0
#12 0x00002aaaab797dea in ?? () from /usr/lib/libgstreamer-0.10.so.0
#13 0x00002aaaab7845f1 in ?? () from /usr/lib/libgstreamer-0.10.so.0
#14 0x00002aaaab794bdc in gst_element_change_state ()
   from /usr/lib/libgstreamer-0.10.so.0
#15 0x00002aaaab797dea in ?? () from /usr/lib/libgstreamer-0.10.so.0
#16 0x00002aaaab7845f1 in ?? () from /usr/lib/libgstreamer-0.10.so.0
#17 0x00002aaab99d4ef8 in ?? ()
   from /usr/lib/gstreamer-0.10/libgstgconfelements.so
#18 0x00002aaaab794bdc in gst_element_change_state ()
   from /usr/lib/libgstreamer-0.10.so.0
#19 0x00002aaaab797dea in ?? () from /usr/lib/libgstreamer-0.10.so.0
#20 0x000000000044f70f in bacon_video_widget_new (width=-1,
    height=<value optimised out>, type=BVW_USE_TYPE_VIDEO,
    error=<value optimised out>) at bacon-video-widget-gst-0.10.c:6276
#21 0x000000000042854f in video_widget_create (totem=0x8ff090)
    at totem-object.c:4048
#22 0x0000000000422254 in main (argc=1, argv=0x7fffffffe668) at totem.c:235
---

Revision history for this message
Sebastien Bacher (seb128) wrote :

why do you think it's a glib bug? should be sent to upstream in any case to be discussed if that's one

Revision history for this message
pablomme (pablomme) wrote :

The problem is that glib is failing to start a thread with the scheduling priority of the parent thread. In particular, eglibc is reporting that the requested priority is out of range. So something somewhere is deciding that I am not allowed to set the real-time priority of a thread, which is obviously wrong since I was allowed to launch the process with a modified priority in the first place.

I've tried qt applications (hydrogen and kdenlive, both likely to be multithreaded) and there is no problem with them. So although I may as well be blaming the messenger, there is a good chance that it's GNOME's libraries that are at fault here.

Revision history for this message
pablomme (pablomme) wrote :

Does my reasoning sound sensible to you? Should this be forwarded upstream then?

Revision history for this message
Sebastien Bacher (seb128) wrote :

Not sure about the issue, it seems rather a corner case and the current team can't work on every bug filed there, yours seem a special case and not something that will be worked in ubuntu any time soon, better to open it upstream too yes

Changed in glib2.0 (Ubuntu):
status: Incomplete → New
Revision history for this message
Sebastien Bacher (seb128) wrote :

changing to new until it's sent to GNOME

Changed in glib2.0 (Ubuntu):
importance: Medium → Low
Revision history for this message
Sebastien Bacher (seb128) wrote :

updating to low importance too since it's not a common usecase there

Revision history for this message
pablomme (pablomme) wrote :
Revision history for this message
Loïc Minier (lool) wrote :

Thanks a lot

Revision history for this message
Loïc Minier (lool) wrote :

I tried "chrt -f 50 totem" and can't reproduce on karmic; perhaps I need a special kernel or something?

Revision history for this message
Loïc Minier (lool) wrote :

Oh right, -rt kernel; ok, I think that's a valid issue but as seb128 said, it's not critical since it's our first report; upstream is certainly interested in fixing it I guess.

Revision history for this message
pablomme (pablomme) wrote :

It happens with the -generic kernel too, but if you haven't modified /etc/security/limits.conf your regular user account won't be allowed to chrt anything. Try "sudo chrt 50 totem" to reproduce the problem without changing those settings.

Side note: chrt-ing applications is a common thing to do for semi-pro audio applications, which is mostly what you want UbuntuStudio for. Perhaps the UbuntuStudio maintainers should be subscribed to this bug?

Changed in glib2.0 (Ubuntu):
status: New → Triaged
Changed in glib2.0 (Ubuntu):
status: Triaged → In Progress
assignee: nobody → Kamal Mostafa (kamalmostafa)
Revision history for this message
Kamal Mostafa (kamalmostafa) wrote :

I have fixed this problem (and the related LP bug 501699) and produced update packages for karmic and lucid, available in my PPA here:

    https://launchpad.net/~kamalmostafa/+archive/glib2.0-fixes

The patch has been contributed upstream but has not yet been reviewed or integrated by the glib development team (see the gnome bug report https://bugzilla.gnome.org/show_bug.cgi?id=599079 ).

Revision history for this message
Kamal Mostafa (kamalmostafa) wrote :

Upstream bug report https://bugzilla.gnome.org/show_bug.cgi?id=599079 still awaiting review.

Changed in glib2.0 (Ubuntu):
assignee: Kamal Mostafa (kamalmostafa) → nobody
status: In Progress → Confirmed
Changed in glib2.0 (Ubuntu):
status: Confirmed → Triaged
Changed in glib:
importance: Unknown → Medium
status: Unknown → New
Changed in glib:
status: New → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.