Bug 827748 - jackd always starts in verbose mode
jackd always starts in verbose mode
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: gcc (Show other bugs)
19
Unspecified Linux
unspecified Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-02 16:05 EDT by Fernando Lopez-Lezcano
Modified: 2015-02-16 21:05 EST (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-02-14 11:05:14 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
jack stop verbose (21.11 KB, patch)
2012-06-02 22:36 EDT, Orcan Ogetbil
no flags Details | Diff
init of jackctl_parameter_value in jackctl_server_create (2.35 KB, patch)
2012-06-09 16:59 EDT, Brendan Jones
no flags Details | Diff

  None (edit)
Description Fernando Lopez-Lezcano 2012-06-02 16:05:06 EDT
Description of problem:
Jackd starts with "verbose" on regardless of the value of the --verbose or --silent flags. Tons of information and debugging messages are printed out. 

Version-Release number of selected component (if applicable):
jack-audio-connection-kit-1.9.8-8.fc17.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Start jackd, for example in the command line type:
   jackd -R -d alsa -d hw:0
(assuming you have a soundcard in hw:0)
  
Actual results:
Debugging output is printed to the terminal. 

Expected results:
Only the normal startup messages should be printed. 

Additional info:
There is an ongoing thread in linux-audio-users and jack-devel about this issue. It almost certainly linked to the use of g++ 4.7.0 (Arch is also affected) and the handling of the boolean value (part of a union, I think) in the test for verbosity. Apparently compiling with -O0 fixes this but it would be better to come up with a patch. 

See:
http://linuxaudio.org/mailarchive/lau/2012/5/29/190667

I set "severity" to medium but it is an important issue. For big setups (lots of channels, lots of applications) jack2 can print __many__ messages in verbose mode, so many that it makes jack2 almost useless.
Comment 1 Orcan Ogetbil 2012-06-02 22:36:24 EDT
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.
Comment 2 Brendan Jones 2012-06-03 16:42:55 EDT

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:
Comment 3 Brendan Jones 2012-06-03 18:51:33 EDT
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
Comment 4 Brendan Jones 2012-06-04 03:00:58 EDT

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);
Comment 5 Brendan Jones 2012-06-04 16:14:54 EDT
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);
Comment 6 Orcan Ogetbil 2012-06-04 20:32:37 EDT
Neat. It seems to work here too! I didn't look into the code but should it be '!=' perhaps instead of '>' ?
Comment 7 Brendan Jones 2012-06-04 21:50:18 EDT
Your right actually, because the boolean value of an int should only be looking at the least signigicant bit.
Comment 8 Brendan Jones 2012-06-04 21:51:05 EDT
A simple cast should work as well I suppose
Comment 9 Orcan Ogetbil 2012-06-04 22:16:36 EDT
We can file an update once we settle bug 827655.
Comment 10 Brendan Jones 2012-06-04 22:58:02 EDT
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
Comment 11 Brendan Jones 2012-06-05 05:36:26 EDT
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.
Comment 12 Fernando Lopez-Lezcano 2012-06-05 21:06:39 EDT
(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...).
Comment 13 Orcan Ogetbil 2012-06-05 21:11:38 EDT
Fernando, please try Brendan's "fix" from comment 10. It seems to stop the verbosity, even with -O2.
Comment 14 Brendan Jones 2012-06-06 00:24:53 EDT
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.
Comment 15 Orcan Ogetbil 2012-06-06 21:13:01 EDT
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?
Comment 17 Orcan Ogetbil 2012-06-08 19:39:14 EDT
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?
Comment 18 Brendan Jones 2012-06-09 16:57:57 EDT
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.
Comment 19 Brendan Jones 2012-06-09 16:59:52 EDT
Created attachment 590659 [details]
init of jackctl_parameter_value in jackctl_server_create
Comment 20 Brendan Jones 2012-06-14 03:52:34 EDT
Logged upstream here:

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

No gcc 4.7.1 build in rawhide yet
Comment 21 Orcan Ogetbil 2012-06-20 23:25:35 EDT
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?
Comment 22 Fernando Lopez-Lezcano 2012-06-21 00:29:49 EDT
(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).
Comment 23 Brendan Jones 2012-06-21 03:24:34 EDT
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.
Comment 24 Fedora Update System 2012-09-23 21:31:17 EDT
tuxguitar-1.2-9.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/tuxguitar-1.2-9.fc18
Comment 25 Orcan Ogetbil 2012-09-23 21:34:20 EDT
Sorry for the noise, I entered the wrong bug id in bodhi. Now I changed it.
Comment 26 Orcan Ogetbil 2012-10-07 21:23:01 EDT
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
Comment 27 Fedora Update System 2012-10-28 01:27:16 EDT
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
Comment 28 Fedora Update System 2012-10-28 01:27:23 EDT
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
Comment 29 Orcan Ogetbil 2012-10-28 01:28:57 EDT
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.
Comment 30 Fedora Update System 2012-10-28 12:35:35 EDT
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).
Comment 31 Fedora Update System 2012-11-14 21:29:27 EST
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.
Comment 32 Fernando Lopez-Lezcano 2012-11-15 14:52:35 EST
(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).
Comment 33 Orcan Ogetbil 2012-11-16 00:24:32 EST
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
Comment 34 Ian Malone 2012-11-16 19:18:31 EST
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.
Comment 35 Guido Aulisi 2012-11-19 08:44:17 EST
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.
Comment 36 Guido Aulisi 2012-11-19 08:46:01 EST
Sorry, I wrote the comment to the wrong bug (#814915), but I think they are related.
Comment 37 Orcan Ogetbil 2012-11-19 08:51:35 EST
Hi Guido, if you have time, could you try my optimized build from
   http://oget.fedorapeople.org/jack/
Thanks!
Comment 38 Guido Aulisi 2012-11-20 16:34:05 EST
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.
Comment 39 Brendan Jones 2012-11-20 16:41:52 EST
Thanks for that. I've submitted a new build for rawhide. F17/F18 did not have this error
Comment 40 Fedora End Of Life 2013-07-04 01:52:14 EDT
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.
Comment 41 Fedora End Of Life 2013-08-01 13:09:12 EDT
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.
Comment 42 Orcan Ogetbil 2013-08-01 19:54:43 EDT
I think this is not fixed yet. We are still using the -O0 workaround. Reopening.
Comment 43 Fedora End Of Life 2015-01-09 16:58:38 EST
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.
Comment 44 Marek Polacek 2015-02-12 04:33:31 EST
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.
Comment 45 Brendan Jones 2015-02-14 11:05:14 EST
This is fixed. Closing
Comment 46 Orcan Ogetbil 2015-02-14 23:16:32 EST
Hi Breandan,
Are you sure? We still have 
   export CPPFLAGS="$RPM_OPT_FLAGS -O0"
in the SPEC file. Should we remove the -O0 ?
Comment 47 Orcan Ogetbil 2015-02-15 18:05:11 EST
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?
Comment 48 Ian Malone 2015-02-16 21:05:04 EST
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.)

Note You need to log in before you can comment on or make changes to this bug.