24 Jun
2006
24 Jun
'06
8:26 p.m.
Hi peeps.
I've just been running an app through valgrind and I'm getting a few
of these:
==11955== Syscall param write(buf) points to uninitialised byte(s)
==11955== at 0x4D51BDB: (within /lib64/libpthread-2.4.so)
==11955== by 0x4B27CDD: (within /usr/lib64/libjack.so.0.0.23)
==11955== by 0x4B29434: jack_deactivate (in
/usr/lib64/libjack.so.0.0.23)
==11955== by 0x4B2945F: jack_client_close (in
/usr/lib64/libjack.so.0.0.23)
==11955== by 0x40402F: jackpart_close() (jackPart.cc:86)
==11955== by 0x40235F: mainLoop() (sampleplayer.cpp:438)
==11955== by 0x40237B: main (sampleplayer.cpp:444)
==11955== Address 0x7FEFFE934 is on thread 1's stack
I can't see anything wrong on my part, so I thought I'd check with
people who know more than I before I tear my program apart.
I also get them coming from jack_port_register, jack_activate and
jack_connect.
Any ideas?
James
24 Jun
24 Jun
10:03 p.m.
On Sat, 2006-06-24 at 23:26 +0100, james(a)dis-dot-dat.net wrote:
Hi peeps.
I've just been running an app through valgrind and I'm getting a few
of these:
==11955== Syscall param write(buf) points to uninitialised byte(s)
==11955== at 0x4D51BDB: (within /lib64/libpthread-2.4.so)
==11955== by 0x4B27CDD: (within /usr/lib64/libjack.so.0.0.23)
==11955== by 0x4B29434: jack_deactivate (in
/usr/lib64/libjack.so.0.0.23)
==11955== by 0x4B2945F: jack_client_close (in
/usr/lib64/libjack.so.0.0.23)
==11955== by 0x40402F: jackpart_close() (jackPart.cc:86)
==11955== by 0x40235F: mainLoop() (sampleplayer.cpp:438)
==11955== by 0x40237B: main (sampleplayer.cpp:444)
==11955== Address 0x7FEFFE934 is on thread 1's stack
I can't see anything wrong on my part, so I thought I'd check with
people who know more than I before I tear my program apart.
I also get them coming from jack_port_register, jack_activate and
jack_connect.
they don't matter. they are the result of writing a byte to a FIFO to
wake up an(other) client. the contents of the byte do not make any
difference at any point.
--p
10:30 p.m.
New subject: [Jackit-devel] [linux-audio-dev] What valgrind says
Paul Davis wrote:
they don't matter. they are the result of writing
a byte to a FIFO to
wake up an(other) client. the contents of the byte do not make any
difference at any point.
Regardless of whether this is a bug or not it would be really
nice if this could be fixed. Fixing it means that other people
valgrinding their apps which use the Jack libs don't see warnings
about Jack.
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo
+-----------------------------------------------------------+
"Christianity has a nasty habit of ignoring the major problems of our time,
including overpopulation and exhaustion of resources, because they aren't
mentioned in the Bible."
-- Paula L. Craig
--
+-----------------------------------------------------------+
Erik de Castro Lopo
+-----------------------------------------------------------+
"War is deceit."
-- Islam's prophet Mohammed (Hadith 4:268)
25 Jun
25 Jun
6:34 p.m.
New subject: [Jackit-devel] [linux-audio-dev] What valgrind says
On Sun, 2006-06-25 at 10:29 +1000, Erik de Castro Lopo wrote:
Paul Davis wrote:
++
The last thing we need is MORE valgrind warnings..
-DR-
they don't matter. they are the result of
writing a byte to a FIFO to
wake up an(other) client. the contents of the byte do not make any
difference at any point.
Regardless of whether this is a bug or not it would be really
nice if this could be fixed. Fixing it means that other people
valgrinding their apps which use the Jack libs don't see warnings
about Jack. 
6:49 p.m.
New subject: [Jackit-devel] [linux-audio-dev] What valgrind says
On Sun, 2006-06-25 at 16:34 -0400, Dave Robillard wrote:
On Sun, 2006-06-25 at 10:29 +1000, Erik de Castro Lopo
wrote:
I have not looked closely at the code, but could it be considered an
information leak if you're using a byte of unitialized data?
Lee
Paul Davis wrote:
++
The last thing we need is MORE valgrind warnings.. they don't matter. they are the result of
writing a byte to a FIFO to
wake up an(other) client. the contents of the byte do not make any
difference at any point.
Regardless of whether this is a bug or not it would be really
nice if this could be fixed. Fixing it means that other people
valgrinding their apps which use the Jack libs don't see warnings
about Jack.
6:55 p.m.
New subject: [Jackit-devel] [linux-audio-dev] What valgrind says
Lee Revell wrote:
I have not looked closely at the code, but could it be
considered an
information leak if you're using a byte of unitialized data?
If that data is an automatic (ie stack) variable, then yes.
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo
+-----------------------------------------------------------+
"We must not forget that Allah's rules have to be established in all
lands."
-- Imam Muzammil H. Siddiqi of the Islamic Society of North America
11:23 p.m.
New subject: [Jackit-devel] [linux-audio-dev] What valgrind says
On Sun, 2006-06-25 at 16:49 -0400, Lee Revell wrote:
On Sun, 2006-06-25 at 16:34 -0400, Dave Robillard
wrote:
If you ask me using a byte of uninitialized data is an error, period
(even if technically the value of that byte isn't relevant, as in this
case).
Uninitialized /anything/ is just asking for trouble...
-DR-
On Sun, 2006-06-25 at 10:29 +1000, Erik de Castro
Lopo wrote:
I have not looked closely at the code, but could it be considered an
information leak if you're using a byte of unitialized data? Paul Davis wrote:
++
The last thing we need is MORE valgrind warnings.. they don't matter. they are the result of
writing a byte to a FIFO to
wake up an(other) client. the contents of the byte do not make any
difference at any point.
Regardless of whether this is a bug or not it would be really
nice if this could be fixed. Fixing it means that other people
valgrinding their apps which use the Jack libs don't see warnings
about Jack. 
26 Jun
26 Jun
1:16 p.m.
New subject: [Jackit-devel] [linux-audio-dev] What valgrind says
On 6/25/06, Dave Robillard <drobilla(a)connect.carleton.ca> wrote:
On Sun, 2006-06-25 at 16:49 -0400, Lee Revell wrote:
libjack seems OK already, but there was an unitialied char
written by jackd. I fixed that and committed it as [0.102.18].
I don't have valgrind set up correctly on my new laptop. Could
one of you please update to the latest SVN version and verify
whether this fixes that warning message?
--
joq
On Sun, 2006-06-25 at 16:34 -0400, Dave Robillard
wrote:
If you ask me using a byte of uninitialized data is an error, period
(even if technically the value of that byte isn't relevant, as in this
case).
Uninitialized /anything/ is just asking for trouble... On Sun, 2006-06-25 at 10:29 +1000, Erik de Castro
Lopo wrote:
I have not looked closely at the code, but could it be considered an
information leak if you're using a byte of unitialized data? Regardless of whether this is a bug or not it
would be really
nice if this could be fixed. Fixing it means that other people
valgrinding their apps which use the Jack libs don't see warnings
about Jack.
++
The last thing we need is MORE valgrind warnings..
9:05 p.m.
New subject: [Jackit-devel] [linux-audio-dev] What valgrind says
On Mon, 26 Jun, 2006 at 10:16AM -0500, Jack O'Quin spake thus:
On 6/25/06, Dave Robillard
<drobilla(a)connect.carleton.ca> wrote:
OK, since I brought it up I thought I'd better test it out. Sorry,
but I still get the same problem.
Compiling from the raw SVN-delivered source instead of emerging it
might have given a bit of a hint, though. Valgrind is now able to
give the location inside jack that the error occurs: client.c, line
240
I've attached a log from valgrind (includes my own debugging output,
easily ignored).
Hope that helps!
James
On Sun, 2006-06-25 at 16:49 -0400, Lee Revell
wrote:
libjack seems OK already, but there was an unitialied char
written by jackd. I fixed that and committed it as [0.102.18].
I don't have valgrind set up correctly on my new laptop. Could
one of you please update to the latest SVN version and verify
whether this fixes that warning message? On Sun, 2006-06-25 at 16:34 -0400, Dave Robillard
wrote:
If you ask me using a byte of uninitialized data is an error, period
(even if technically the value of that byte isn't relevant, as in this
case).
Uninitialized /anything/ is just asking for trouble... On Sun, 2006-06-25 at 10:29 +1000, Erik de Castro
Lopo wrote:
> Regardless of whether this is a bug or not it would be really
> nice if this could be fixed. Fixing it means that other people
> valgrinding their apps which use the Jack libs don't see warnings
> about Jack.
++
The last thing we need is MORE valgrind warnings..
I have not looked closely at the code, but could it be considered an
information leak if you're using a byte of unitialized data?
27 Jun
27 Jun
12:07 a.m.
New subject: [Jackit-devel] [linux-audio-dev] What valgrind says
On 6/26/06, james(a)dis-dot-dat.net <james(a)dis-dot-dat.net> wrote:
On Mon, 26 Jun, 2006 at 10:16AM -0500, Jack O'Quin
spake thus:
OK, I see it now. All those uninitialized write complaints are due to
the fact that jack_request_t is a union. Most requests don't need (or
want) to fill in all the bytes, just the ones that matter for that
RequestType.
There are jack_request_t structs used all over the place. The only
solution I can think of that would make valgrind happy would be to
initialize them all to zeroes before filling them in. While that would
eliminate these complaints, I have some doubts that we really want
to make all those changes. There is some risk of introducing real
bugs while fixing them.
Those valgrind warnings really *are* annoying, of course.
--
joq
libjack seems OK already, but there was an
unitialied char
written by jackd. I fixed that and committed it as [0.102.18].
I don't have valgrind set up correctly on my new laptop. Could
one of you please update to the latest SVN version and verify
whether this fixes that warning message?
OK, since I brought it up I thought I'd better test it out. Sorry,
but I still get the same problem.
Compiling from the raw SVN-delivered source instead of emerging it
might have given a bit of a hint, though. Valgrind is now able to
give the location inside jack that the error occurs: client.c, line
240
I've attached a log from valgrind (includes my own debugging output,
easily ignored). 
5 Jul
5 Jul
3:22 p.m.
New subject: [Jackit-devel] [linux-audio-dev] What valgrind says
On 6/26/06, Jack O'Quin <jack.oquin(a)gmail.com> wrote:
OK, I see it now. All those uninitialized write
complaints are due to
the fact that jack_request_t is a union. Most requests don't need (or
want) to fill in all the bytes, just the ones that matter for that
RequestType.
There are jack_request_t structs used all over the place. The only
solution I can think of that would make valgrind happy would be to
initialize them all to zeroes before filling them in. While that would
eliminate these complaints, I have some doubts that we really want
to make all those changes. There is some risk of introducing real
bugs while fixing them.
Those valgrind warnings really *are* annoying, of course.
--
joq
Use valgrind's --gen-suppressions=yes option, create a suppressions
file, and post it to the list for all to enjoy.
24 Jun
24 Jun
10:44 p.m.
On Sat, 24 Jun, 2006 at 08:04PM -0400, Paul Davis spake thus:
On Sat, 2006-06-24 at 23:26 +0100,
james(a)dis-dot-dat.net wrote:
Okey dokey. Cheers.
James
Hi peeps.
I've just been running an app through valgrind and I'm getting a few
of these:
==11955== Syscall param write(buf) points to uninitialised byte(s)
==11955== at 0x4D51BDB: (within /lib64/libpthread-2.4.so)
==11955== by 0x4B27CDD: (within /usr/lib64/libjack.so.0.0.23)
==11955== by 0x4B29434: jack_deactivate (in
/usr/lib64/libjack.so.0.0.23)
==11955== by 0x4B2945F: jack_client_close (in
/usr/lib64/libjack.so.0.0.23)
==11955== by 0x40402F: jackpart_close() (jackPart.cc:86)
==11955== by 0x40235F: mainLoop() (sampleplayer.cpp:438)
==11955== by 0x40237B: main (sampleplayer.cpp:444)
==11955== Address 0x7FEFFE934 is on thread 1's stack
I can't see anything wrong on my part, so I thought I'd check with
people who know more than I before I tear my program apart.
I also get them coming from jack_port_register, jack_activate and
jack_connect.
they don't matter. they are the result of writing a byte to a FIFO to
wake up an(other) client. the contents of the byte do not make any
difference at any point.
6711
days inactive
6722
days old
linux-audio-dev@lists.linuxaudio.org
11 comments
7 participants
participants (7)
-
Dave Robillard -
Erik de Castro Lopo -
Jack O'Quin -
james＠dis-dot-dat.net -
Lee Revell -
Paul Coccoli -
Paul Davis