Bug 827748

Created attachment 588758 [details]
jack stop verbose

Hi Fernando, thanks for the report. I am following the thread in LAU and jack devel lists as well. I made the attached (rather lame) patch that seems to workaround the issue, at least for me. I don't know if we should use this patch in the RPM though. It looks like gcc's failure with optimizing booleans inside unions.

I have come across a very similar jackdbus error - basically jackbus receives a SIGSEGV via the dbus-daemon on account of a bool value not being 1 or 0. 

Perhaps this crude patch that fixes the issue will explain it better (segfault occurred on the following line):

diff -Nurp jack-1.9.8.orig/dbus/jackdbus.c jack-1.9.8/dbus/jackdbus.c
--- jack-1.9.8.orig/dbus/jackdbus.c	2011-12-19 12:54:24.000000000 +0100
+++ jack-1.9.8/dbus/jackdbus.c	2012-06-03 22:06:16.148799580 +0200
@@ -418,6 +418,7 @@ jack_dbus_message_append_variant(
     }
 
     /* Append the supplied value. */
+    if (type == DBUS_TYPE_BOOLEAN) *arg = (message_arg_t) ((int*)arg>0);
     if (!dbus_message_iter_append_basic (&sub_iter, type, (const void *) arg))
     {
         dbus_message_iter_close_container (iter, &sub_iter);

Where arg is a poinnter to (dbus/jackdbus.c)
typedef union
{
    unsigned char byte;
    dbus_bool_t boolean;
    dbus_int16_t int16;
    dbus_uint16_t uint16;
    dbus_int32_t int32;
    dbus_uint32_t uint32;
    dbus_int64_t int64;
    dbus_uint64_t uint64;
    double doubl;
    const char *string;
} message_arg_t;

Obviously making this a struct will not work in this case. Perhaps this is a GCC regression? I could only find one related to unions - might be a red herring:

In fact, my patch above simply exhibits the same behaviour as the original bug (ie. always true). Accessing the union member arg->boolean results in the same dbus error. 

I can confirm that -O0 fixes this error also, so all things seem to be pointing to GCC

I have tried with -fno-strict-aliasing but yields the same result when jackd is run normally (from qjackctl for example with DBUS disabled). http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#Type-punning  

When jack is in dbus mode the following works (honours all boolean values such as verbose correctly) - dbus_bool_t is actually an unsigned int:

diff -Nurp jack-1.9.8.orig/dbus/jackdbus.c jack-1.9.8/dbus/jackdbus.c
--- jack-1.9.8.orig/dbus/jackdbus.c 2011-12-19 12:54:24.000000000 +0100
+++ jack-1.9.8/dbus/jackdbus.c  2012-06-04 08:09:52.589833947 +0200
@@ -418,6 +418,11 @@ jack_dbus_message_append_variant(
     }

     /* Append the supplied value. */
+    if  (type == DBUS_TYPE_BOOLEAN) 
+    {
+        if ( arg->boolean > 0 ) arg->boolean = TRUE;
+    }
+
     if (!dbus_message_iter_append_basic (&sub_iter, type, (const void *) arg))
     {
         dbus_message_iter_close_container (iter, &sub_iter);

Fernando, are you able to try this? It seems to be working here

diff -Nurp '-x*~' jack-1.9.8.orig/common/JackControlAPI.cpp jack-1.9.8/common/JackControlAPI.cpp
--- jack-1.9.8.orig/common/JackControlAPI.cpp	2011-12-19 12:54:02.000000000 +0100
+++ jack-1.9.8/common/JackControlAPI.cpp	2012-06-04 21:57:59.264581780 +0200
@@ -246,7 +246,7 @@ jackctl_add_driver_parameters(
             break;
         case JackDriverParamBool:
             jackctl_type = JackParamBool;
-            jackctl_value.b = descriptor_ptr->value.i;
+            jackctl_value.b = (descriptor_ptr->value.i > 0);
             break;
         default:
             jack_error("unknown driver parameter type %i", (int)descriptor_ptr->type);

Neat. It seems to work here too! I didn't look into the code but should it be '!=' perhaps instead of '>' ?

Your right actually, because the boolean value of an int should only be looking at the least signigicant bit.

A simple cast should work as well I suppose

We can file an update once we settle bug 827655.

Can we push ahead? It seems unlikey that that issue will be sovled by a jack commit. I'm happy to do it if you like

This is a show stopper for any jackdbus application at the moment (SIGSEGV). The jackdbus.c patch above is not required.

diff -Nurp '-x*~' jack-1.9.8.orig/common/JackControlAPI.cpp jack-1.9.8/common/JackControlAPI.cpp
--- jack-1.9.8.orig/common/JackControlAPI.cpp	2011-12-19 12:54:02.000000000 +0100
+++ jack-1.9.8/common/JackControlAPI.cpp	2012-06-04 21:57:59.264581780 +0200
@@ -246,7 +246,7 @@ jackctl_add_driver_parameters(
             break;
         case JackDriverParamBool:
             jackctl_type = JackParamBool;
-            jackctl_value.b = descriptor_ptr->value.i;
+            jackctl_value.b = (bool) descriptor_ptr->value.i;
             break;
         default:
             jack_error("unknown driver parameter type %i", (int)descriptor_ptr->type);

While we are at it there's another jackdbus patch upstream which prevents  SIGSEGV occurring in jackdbus error handling - I noticed this while debugging this issue (or would you prefer separate updates?):

https://github.com/adiknoth/jack2/commit/f82ec71566b2c18f159004e00a70c2cf3e46d755

I'd hold off on this. I seems that there is still some undefined behaviour.

Fernando - when it was working for you did you have DBUS enabled? It seems that its the jackdbus.c change that was giving us some success, not the one above.

(In reply to comment #11)
> I'd hold off on this. I seems that there is still some undefined behaviour.
> 
> Fernando - when it was working for you did you have DBUS enabled? It seems
> that its the jackdbus.c change that was giving us some success, not the one
> above.

Sorry, I have not had a chance to test anything yet. It would seem to me the safest route would be to do a build with -O0 (instead of the default -O2) - from what I read in the list that seems to get rid of all the problems until there is a proper fix posted (I have not read the list today, jury duty...).

Fernando, please try Brendan's "fix" from comment 10. It seems to stop the verbosity, even with -O2.

Orcan, it seems that was a red herring (it was actually the jackdbus patch which provides some success which I was still applying - sorry)

Unfortunately this has no affect when running jackd when running without (in fact Nedko pointed out to me that there are two verbose parameters - a driver parameter (for FFADO and the like) and another for the daemon. 

I'll try and strip it down to an isolated example for GCC but won't be for a while yet. Perhaps -O0 is the safest bet for now as this affects all bools in this union it seems.

That is weird. The patch from comment 5 or from comment 10 works in my system, without any further modification, other than the already existing patches in the jack package. When I say "works", I mean that jack does not turn verbose during regular startup. Is that not the case for you?

http://permalink.gmane.org/gmane.comp.audio.jackit/26057

Quite interesting. -O1 prints 10, -O0 and -O2 print 0.
I wrote a similar test code but I only tried -O0 and -O2, so I could not catch the bug. The weird thing is, Fedora packages get compiled with -O2. So why did we experience the bug?
Did anyone file this against component gcc yet?

Thanks for that Nedko - if you haven't filed a bug already with gcc I can.

I had a play around with the function attributes. If I used noinline, -O2 also produced the erroneous behaviour. If I used always_inline all optimizations worked correctly. 

As a workaround, I tried explicitly intialising all members of the union in jackctl_server_create. This seems to fix the issue (patch attached below) but there are potentially other places where this could happen.

Created attachment 590659 [details]
init of jackctl_parameter_value in jackctl_server_create

Logged upstream here:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53663

No gcc 4.7.1 build in rawhide yet

Still no gcc build. I will build jack with -O0 and keep it that way until this issue is resolved. Otherwise Fedora 17 is pretty much unusable for us. Any objections? How much performance would this sacrifice? 

Brendan, is this the only place you filed the gcc bug ? any mailing lists, this bugzilla etc?

(In reply to comment #21)
> Still no gcc build. I will build jack with -O0 and keep it that way until
> this issue is resolved. 

I agree. Please rebuild if you can. 

> Otherwise Fedora 17 is pretty much unusable for us.
> Any objections? How much performance would this sacrifice? 

At this point I don't think a performance hit matters. Current Jack is not really usable in the state it is (I'm trying to deploy fc17 at ccrma and I'm not there yet, still fighting other <unprintable> problems, if I had to do it today I would have to do a local jack build overriding Fedora's).

I agree, I've been running it this way for the last couple of weeks. Bascially any jackdbus application is broken as it stands and supercollider for example is also unusable.

tuxguitar-1.2-9.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/tuxguitar-1.2-9.fc18

Sorry for the noise, I entered the wrong bug id in bodhi. Now I changed it.

It seems that the issue is fixed by gcc upstream. 

gcc maintainer, could you apply the patch from upstream bug 53663 to the Fedora package? Thanks.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53663#c15

jack-audio-connection-kit-1.9.8-12.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/jack-audio-connection-kit-1.9.8-12.fc18

jack-audio-connection-kit-1.9.8-10.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/jack-audio-connection-kit-1.9.8-10.fc17

It looks to me that our gcc-4.7.2 was built with this issue fixed. The above are optimized (-O2) jack builds. Please test and see if everything works fine.

Package jack-audio-connection-kit-1.9.8-12.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing jack-audio-connection-kit-1.9.8-12.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-17128/jack-audio-connection-kit-1.9.8-12.fc18
then log in and leave karma (feedback).

jack-audio-connection-kit-1.9.8-10.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.

(In reply to comment #31)
> jack-audio-connection-kit-1.9.8-10.fc17 has been pushed to the Fedora 17
> stable repository.  If problems still persist, please make note of it in
> this bug report.

Sorry, I still see verbose mode "on" on Fedora 17... (tested with "jackd -R -d alsa -d hw:0" in the command line).

Hi Fernando,
Yes this is partly my fault. I asked for help in the devel mailing list as I don't know how to resolve the issue. We will probably have to redo our workaround: rebuild unoptimized. Feel free to chime in [1] if you have any ideas. 

I also made an announcement [2] in the music list to warn our folks.

Reopening the bug.

[1] http://lists.fedoraproject.org/pipermail/devel/2012-November/174315.html
[2] http://lists.fedoraproject.org/pipermail/music/2012-November/001444.html

From build dates F17 gcc up to gcc-4.7.2-2.fc17 (24th Sep) are too old to contain the fix from upstream (dated 25th Sep). gcc-4.7.2-3.fc18 and gcc-4.7.2-8.fc18 are after it, but don't include the fix either (or at least don't pass the upstream test). Current builds of jackd still show the problem as Orcan notes.

With jack-audio-connection-kit-1.9.8-10.fc17.x86_64 the problem seems to be here again. Somehow the optimized build breaks jack in an obscure way.

Sorry, I wrote the comment to the wrong bug (#814915), but I think they are related.

Hi Guido, if you have time, could you try my optimized build from
   http://oget.fedorapeople.org/jack/
Thanks!

I'll try ASAP. I got the problem only once, maybe it's something different.
By the way I noticed that release 13 of the spec file has an error:

export CPPFLAGS="$RPM_OPT_FLAGS -DJACK_32_64i -O0"

There's an extra 'i' after JACK_32_64.

Thanks for that. I've submitted a new build for rawhide. F17/F18 did not have this error

This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

I think this is not fixed yet. We are still using the -O0 workaround. Reopening.

This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Can you try gcc-5 in F22?  If this is not fixed, can you provide some steps to reproduce?  I lost track of how to reproduce the issue.

This is fixed. Closing

Hi Breandan,
Are you sure? We still have 
   export CPPFLAGS="$RPM_OPT_FLAGS -O0"
in the SPEC file. Should we remove the -O0 ?

I made this scratch build without the -O0 flag, and I don't see the verbose messages issue on my computer.

http://koji.fedoraproject.org/koji/taskinfo?taskID=8941549

Could you folks verify?

Looks fine, thanks:

[ian@localhost ~]$  jackd -R -d alsa -d hw:0
jackdmp 1.9.10
Copyright 2001-2005 Paul Davis and others.
Copyright 2004-2014 Grame.
jackdmp comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
no message buffer overruns
no message buffer overruns
no message buffer overruns
JACK server starting in realtime mode with priority 20
self-connect-mode is "Don't restrict self connect requests"
audio_reservation_init
Acquire audio card Audio0
creating alsa driver ... hw:0|hw:0|1024|2|48000|0|0|nomon|swmeter|-|32bit
configuring for 48000Hz, period = 1024 frames (21.3 ms), buffer = 2 periods
ALSA: final selected sample format for capture: 16bit little-endian
ALSA: use 2 periods for capture
ALSA: final selected sample format for playback: 16bit little-endian
ALSA: use 2 periods for playback
Using port names patch v0.1 (07.04.2010)
Trying to load portnames from /home/ian/.config/jack/cards/HDA Intel.ss.ports.in
Trying to load portnames from /home/ian/.config/jack/cards/HDA Intel.ports.in
Trying to load portnames from /etc/jack/cards/HDA Intel.ss.ports.in
Trying to load portnames from /etc/jack/cards/HDA Intel.ports.in
Trying to load portnames from /home/ian/.config/jack/cards/HDA Intel.ss.ports.out
Trying to load portnames from /home/ian/.config/jack/cards/HDA Intel.ports.out
Trying to load portnames from /etc/jack/cards/HDA Intel.ss.ports.out
Trying to load portnames from /etc/jack/cards/HDA Intel.ports.out
^CJack main caught signal 2
Released audio card Audio0
audio_reservation_finish
[ian@localhost ~]$ rpm -q jack-audio-connection-kit
jack-audio-connection-kit-1.9.10-1.1.fc21.x86_64

(Also, for whatever reason, running jack in a VM no longer brings it to a crawl, but slightly different hardware from last time I tried.)