valgrind-users — General discussion list for Valgrind users

RE: [Valgrind-users] [OT] aggressive legalese [was: Is there a wa y to make uninitialised data warnings display as soon as it is moved?]

[Vincent Penquerc'h <Vin...@ar...>]

> replying to an email -- or if they're just scare tactics?

Probably mostly scare. It costs nothing.
It may also be to protect the company from any loss or perceived
loss from any lawsuit from shareholders, who could say the company
did not follow due diligence in protecting its information from
others. Now, I don't know about the efficiency of it, but it's
like spam: it costs nothing, so why not do it, just in case we
get a 0.0000000001% benefit from it.

-- 
Vincent Penquerc'h 

[Valgrind-users] [OT] aggressive legalese [was: Is there a way to make uninitialised data warnings display as soon as it is moved?]

[Nicholas N. <nj...@ca...>]

> > This message (including any attachments) contains confidential
> > information intended for a specific individual and purpose, and is
> > protected by law.  If you are not the intended recipient, you should
> > delete this message.  Any disclosure, copying, or distribution of this
> > message, or the taking of any action based on it, is strictly
> > prohibited.
>
> Just curious:  what law gives this protection?  And how/why are the listed
> actions prohibited?  Am I breaking the supposed prohibition by copying the
> body of the message in my reply?  If action based on the email is
> prohibited, am I breaking the supposed prohibition by even answering it?
>
> Sorry, this is added by the company email system I am working for. Please
> just ignore it. I think it is a good idea to move to some free email
> address. Any suggestion on good free email services will be much
> appreciated. I do have yahoo email and hotmail. But they give me too many
> spams, and also have too free spaces for storing such active email list
> mails.

Yes, I realise this;  lots of companies append similarly aggressive
warnings.

I just wonder if these warnings have any legal basis -- especially when
some of the "prohibitions" are over the top and seemingly prohibit even
replying to an email -- or if they're just scare tactics?

N

[Valgrind-users] Re: Is there a way to make uninitialised data warnings display as soon as it is moved?

[Owen O'M. <ow...@em...>]

> > Is there a way to make uninitialised data warnings display as soon as it
> > is moved?
> 
> No.  And I would guess that you don't want it to be, since it happens
> legitimately quite a lot.

Actually, I would strongly disagree. I tried to make the change
myself, but didn't have enough time and knowledge of valgrind
internals to get it working. The usage scenario goes like:

  1) get report of uninitialized data being branched on
  2) turn on uninitialized data move warnings & rerun test

You're right that you don't want them all of the time, but helping you
back track through the def-use chains to the source of the problem is
a good thing.

  Owen

Re: [Valgrind-users] RedHat 8.0 pthread "problem"

[Julian S. <js...@ac...>]

On Wednesday 11 June 2003 10:08, Beau D. Simensen wrote:
> > > Now, this works outside of valgrind. Pretty well -- I haven't noticed
> > > any problems with it and other memory debugging stuff seems to think it
> > > is OK [for the most part]. I can actually make it "work" in valgrind,
> > > but only if I have --trace-pthread=all set. However, this dumps far too
> > > much info to be useful for me as I have *alot* of mutex
> > > locking/unlocking.

Sidestepping the discussion about whether threads are actually desirable
here or not ..

Get rid of --trace-pthread=all.  Then it deadlocks again, right?
Now run with --trace-syscalls=yes so we can see what syscall it's
really blocking in.

Also ensure you're using 1.9.6.  There was some ungodly hacking around
I did to try and make non-blocking syscalls really not block, following
RH's more recent glibc hackery, and so V's prior to 1.9.6 may behave
differently.

J

Re: [Valgrind-users] Valgrind/Cachegrind stack overflow problem with Wine app

[Julian S. <js...@ac...>]

On Tuesday 10 June 2003 14:39, John Reiser wrote:
> Prashant Verma wrote:
>  > I just reran valgrind 1.9.6-wine with the following
>  > command line (without cachegrind):
>  > valgrind --trace-children=yes wine ./Acrobat.exe
>  > And this time it stopped with :
>  > disInstr: unhandled opcode 0x94 then 0x8B
>
> 0x94 is "xchg %eax,%esp", which is switching stacks: some form of threads
> that is specific to the application.

In which case, the fix is ultra-trivial.  Find the following line
in vg_to_ucode.c:

   case 0x91: /* XCHG eAX,eCX */

and do the obvious thing.  If you verify this works, please let us know
(and send the resulting patch).

J

RE: [Valgrind-users] Is there a way to make uninitialised data wa rnings display as soon as it is moved?

[Gao, J. <JG...@se...>]

> This message (including any attachments) contains confidential 
> information intended for a specific individual and purpose, and is 
> protected by law.  If you are not the intended recipient, you should 
> delete this message.  Any disclosure, copying, or distribution of this 
> message, or the taking of any action based on it, is strictly 
> prohibited.

Just curious:  what law gives this protection?  And how/why are the listed
actions prohibited?  Am I breaking the supposed prohibition by copying the
body of the message in my reply?  If action based on the email is
prohibited, am I breaking the supposed prohibition by even answering it?

Sorry, this is added by the company email system I am working for. Please
just ignore it. I think it is a good idea to move to some free email
address. Any suggestion on good free email services will be much
appreciated. I do have yahoo email and hotmail. But they give me too many
spams, and also have too free spaces for storing such active email list
mails.

Jeff


This message (including any attachments) contains confidential information
intended for a specific individual and purpose, and is protected by law.  If
you are not the intended recipient, you should delete this message.  Any
disclosure, copying, or distribution of this message, or the taking of any
action based on it, is strictly prohibited. 

RE: [Valgrind-users] Is there a way to make uninitialised data wa rnings display as soon as it is moved?

[Nicholas N. <nj...@ca...>]

On Wed, 11 Jun 2003, Gao, Jiafu wrote:

> Totally agree. However, if we can somehow remember the fact (and related
> info) when an uninitialized data is moved, and report the info we just
> remembered when we actually report such warning (as valgrind does now), it
> would be very useful for debug purpose. I don't know how hard, and how much
> overhead this would be though.

At a guess: quite hard, and a lot of overhead.

> This message (including any attachments) contains confidential information
> intended for a specific individual and purpose, and is protected by law.  If
> you are not the intended recipient, you should delete this message.  Any
> disclosure, copying, or distribution of this message, or the taking of any
> action based on it, is strictly prohibited.

Just curious:  what law gives this protection?  And how/why are the listed
actions prohibited?  Am I breaking the supposed prohibition by copying the
body of the message in my reply?  If action based on the email is
prohibited, am I breaking the supposed prohibition by even answering it?

N

RE: [Valgrind-users] Is there a way to make uninitialised data wa rnings display as soon as it is moved?

[Gao, J. <JG...@se...>]

> > Is there a way to make uninitialised data warnings display as soon as 
> > it is moved?

> No.  And I would guess that you don't want it to be, since it happens
legitimately quite a lot.

Totally agree. However, if we can somehow remember the fact (and related
info) when an uninitialized data is moved, and report the info we just
remembered when we actually report such warning (as valgrind does now), it
would be very useful for debug purpose. I don't know how hard, and how much
overhead this would be though.

Jeff


This message (including any attachments) contains confidential information
intended for a specific individual and purpose, and is protected by law.  If
you are not the intended recipient, you should delete this message.  Any
disclosure, copying, or distribution of this message, or the taking of any
action based on it, is strictly prohibited. 

Re: [Valgrind-users] Suppression bug with Memcheck:Value16

[Nicholas N. <nj...@ca...>]

On Wed, 11 Jun 2003, Leonard mckinley wrote:

> Figuring I had the supression rule wrong, I reran with
> --gen-suppressions=yes.  However, when valgrind hit this event in
> the code, it crashed and said:
>
> ==2336== Thread 2:
> ==2336== Use of uninitialised value of size 16
> ==2336==    at 0x40D64260: __nvsym04804 (in
> /usr/lib/libGLcore.so.1.0.3123)
> ==2336==
> ==2336== ---- Print suppression ? --- [Return/N/n/Y/y/C/c] ----
> Memcheck: the `impossible' happened:
>    unexpected size for Value
> Basic block ctr is approximately 104700000

It's a bug/oversight -- Valgrind doesn't support suppressions for 16 byte
value errors.  I will investigate, hopefully get back to you soon.

N

Re: [Valgrind-users] Is there a way to make uninitialised data warnings display as soon as it is moved?

[Nicholas N. <nj...@ca...>]

> Is there a way to make uninitialised data warnings display as soon as it
> is moved?

No.  And I would guess that you don't want it to be, since it happens
legitimately quite a lot.

N

Re: [Valgrind-users] dlopen in GLIBC 2.1

[Madhu M K. <mm...@ya...>]

Hi,

Leonard mckinley <spa...@ya...> said:

> The more general question would be: is there are has anyone thought of
> having a database (web directory) of valgrind suppression rules for
> more commonly used libraries on Linux?

I think Nick/Julian maintain well known suppression rules (*.supp in the
valgrind/ directory 10 AFAIK). I posted some suppresions for RH9 and GTK
sometime ago, you could check in the archives. 

Cheerio,
M

 Madhu M Kurup /* Nemo Me Impune Lacessit */ mmk at yahoo-inc dt com

Re: [Valgrind-users] --gen-suppressions prompting

[Madhu M K. <mm...@ya...>]

Hi,

Leonard mckinley <spa...@ya...> said:

> I really like the new capability, ...except for all the prompting.
> 
> What do you think of a --gen-suppressions={yes|no|ask} option.  "yes"
> would generate suppressions without a prompt for every flagged issue,
> and "ask" would do what yes does now.  I just want it to dump
> everything in a file and when it prompts me I have to sit there and
> bang "y" on the keyboard.

I actually wrote up a different kind of --gen-suppressions. This one did
the following:

--gen-suppressions=yes/filename
 
If you gave it a filename, it would then peacefully keep accumulating
suppressions, keep a count of how many times that suppressions was
generated irrespective of context (eg. a glibc error that shows up from
diff location, same library's problem). And finally it would dump out
suppressions sorted by frequency. Max to min.

	You then have to manually parse the suppression file to remove the
"real leaks". A rule of thumb that I've found works for me is that any
frequency > 20 is usually a library that I can do nothing about.

	Let me cvs up to head, sync up the changes and post a patch.

Cheerio,
M

 Madhu M Kurup /* Nemo Me Impune Lacessit */ mmk at yahoo-inc dt com

Re: [Valgrind-users] dlopen in GLIBC 2.1

[Jarrod K G. <gr...@cs...>]

Interesting. The dlopen() errors that I get are of the following sort:

==6004== 16 bytes in 1 blocks are still reachable in loss record 1 of 3
==6004==    at 0x4015E780: calloc (vg_clientfuncs.c:245)
==6004==    by 0x4022A308: _dlerror_run (in /lib/libdl-2.2.93.so)
==6004==    by 0x40229EC3: dlopen@@GLIBC_2.1 (in /lib/libdl-2.2.93.so)
==6004==    by 0x804BD38: LoadLibraries (Decode.c:43)
==6004==    by 0x8049C2A: main (main.c:102)
==6004==    by 0x420158D3: __libc_start_main (in /lib/i686/libc-2.2.93.so)
==6004==    by 0x8049978: (within /home/bob/test)
==6004==
==6004== 176 bytes in 12 blocks are still reachable in loss record 2 of 3
==6004==    at 0x4015E310: malloc (vg_clientfuncs.c:103)
==6004==    by 0x4000948B: _dl_map_object_deps_internal (in
/lib/ld-2.2.93.so)
==6004==    by 0x4210951A: dl_open_worker (in /lib/i686/libc-2.2.93.so)
==6004==    by 0x4000A425: _dl_catch_error_internal (in /lib/ld-2.2.93.so)
==6004==    by 0x421092BE: __GI__dl_open (in /lib/i686/libc-2.2.93.so)
==6004==    by 0x40229F18: dlopen_doit (in /lib/libdl-2.2.93.so)
==6004==    by 0x4000A425: _dl_catch_error_internal (in /lib/ld-2.2.93.so)
==6004==    by 0x4022A2C3: _dlerror_run (in /lib/libdl-2.2.93.so)
==6004==    by 0x40229EC3: dlopen@@GLIBC_2.1 (in /lib/libdl-2.2.93.so)
==6004==    by 0x804BD38: LoadLibraries (Decode.c:43)
==6004==    by 0x8049C2A: main (main.c:102)
==6004==    by 0x420158D3: __libc_start_main (in /lib/i686/libc-2.2.93.so)
==6004==    by 0x8049978: (within /home/bob/test)

Jarrod

On Wed, 11 Jun 2003, Leonard mckinley wrote:

> Anyone seen this with dlopen() in GLIBC?  Don't think this is my
> app's fault, but would like to be sure.
>
> The more general question would be: is there are has anyone thought of
> having a database (web directory) of valgrind suppression rules for
> more commonly used libraries on Linux?

Re: [Valgrind-users] dlopen in GLIBC 2.1

[Andraz T. <And...@gu...>]

Na 1055359015, 2003-06-11 ob 21:16, je Leonard mckinley napisal(a):
> Anyone seen this with dlopen() in GLIBC?  Don't think this is my
> app's fault, but would like to be sure.

I am getting errors like this:

=3D=3D16113=3D=3D Conditional jump or move depends on uninitialised value(s=
)
=3D=3D16113=3D=3D    at 0x40007AD4: elf_dynamic_do_rel.7 (in /lib/ld-2.3.1.=
so)
=3D=3D16113=3D=3D    by 0x40007FB8: _dl_relocate_object_internal (in
/lib/ld-2.3.1.so)
=3D=3D16113=3D=3D    by 0x40B73053: (within /lib/libc-2.3.1.so)
=3D=3D16113=3D=3D    by 0x400095BD: _dl_catch_error_internal (in
/lib/ld-2.3.1.so)
=3D=3D16113=3D=3D
=3D=3D16113=3D=3D Conditional jump or move depends on uninitialised value(s=
)
=3D=3D16113=3D=3D    at 0x40007AD8: elf_dynamic_do_rel.7 (in /lib/ld-2.3.1.=
so)
=3D=3D16113=3D=3D    by 0x40007FB8: _dl_relocate_object_internal (in
/lib/ld-2.3.1.so)
=3D=3D16113=3D=3D    by 0x40B73053: (within /lib/libc-2.3.1.so)
=3D=3D16113=3D=3D    by 0x400095BD: _dl_catch_error_internal (in
/lib/ld-2.3.1.so)




> The more general question would be: is there are has anyone thought of
> having a database (web directory) of valgrind suppression rules for
> more commonly used libraries on Linux?

That would be cool, also i find valgrind's documentation on writing your
own surpression rules quite incomprehensable.

Bye
Andraz Tori

[Valgrind-users] dlopen in GLIBC 2.1

[Leonard m. <spa...@ya...>]

Anyone seen this with dlopen() in GLIBC?  Don't think this is my
app's fault, but would like to be sure.

The more general question would be: is there are has anyone thought of
having a database (web directory) of valgrind suppression rules for
more commonly used libraries on Linux?

Thanks,

Randall

==2566== Conditional jump or move depends on uninitialised value(s)
==2566==    at 0x40008691: elf_dynamic_do_rel.4 (in /lib/ld-2.2.5.so)
==2566==    by 0x4000896A: _dl_relocate_object (in /lib/ld-2.2.5.so)
==2566==    by 0x40B190C0: dl_open_worker (in /lib/libc.so.6)
==2566==    by 0x40009F95: _dl_catch_error (in /lib/ld-2.2.5.so)
==2566==    by 0x40B191F4: _dl_open (in /lib/libc.so.6)
==2566==    by 0x40226EF8: dlopen_doit (in /lib/libdl.so.2)
==2566==    by 0x40009F95: _dl_catch_error (in /lib/ld-2.2.5.so)
==2566==    by 0x402272F3: _dlerror_run (in /lib/libdl.so.2)
==2566==    by 0x40226F43: dlopen@@GLIBC_2.1 (in /lib/libdl.so.2)


__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com

[Valgrind-users] Suppression bug with Memcheck:Value16

[Leonard m. <spa...@ya...>]

Been valgrinding an large app I have here and just hit a problem.
valgrind gave me a bunch of these down in the NVidia drivers:

==2305== Thread 2:
==2305== Use of uninitialised value of size 16
==2305==    at 0x40D64260: __nvsym04804 (in
/usr/lib/libGLcore.so.1.0.3123)

Deciding to check my code later, I added:

{
   nvidia_1.0_3123_008
   Memcheck:Value16
   fun:__nvsym04804
}

to my suppressions file.  But valgrind refused to parse this.

Figuring I had the supression rule wrong, I reran with 
--gen-suppressions=yes.  However, when valgrind hit this event in
the code, it crashed and said:

==2336== Thread 2:
==2336== Use of uninitialised value of size 16
==2336==    at 0x40D64260: __nvsym04804 (in
/usr/lib/libGLcore.so.1.0.3123)
==2336== 
==2336== ---- Print suppression ? --- [Return/N/n/Y/y/C/c] ---- 
Memcheck: the `impossible' happened:
   unexpected size for Value
Basic block ctr is approximately 104700000

sched status:
...

Any ideas?

Thanks,

Randall


__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com

Re: [Valgrind-users] --gen-suppressions prompting

[Alex I. <ale...@in...>]

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
I agree completely with the first suggestion.&nbsp; Especially for some
of my apps that run as daemons and&nbsp; are cut off from tty completely
- there is no way to get the valgrind prompt and&nbsp; reply to it (all
valgrind output is going to a log file).
<p>Alex
<p>Leonard mckinley wrote:
<blockquote TYPE=CITE>I really like the new capability, ...except for all
the prompting.
<p>What do you think of a --gen-suppressions={yes|no|ask} option.&nbsp;
"yes"
<br>would generate suppressions without a prompt for every flagged issue,
<br>and "ask" would do what yes does now.&nbsp; I just want it to dump
<br>everything in a file and when it prompts me I have to sit there and
<br>bang "y" on the keyboard.
<p>A less desirable second choice would be to add another option to the
<br>prompt.&nbsp; Currently we have "no this time", "yes this time", and
<br>"no this time and for all future occurances".&nbsp; A "yes this time
and for
<br>all future occurances" would do it, but you'd still need to
<br>answer that first prompt, even if you'd routed the valgrind output
to a
<br>file.
<p>Thanks,
<p>Randall
<p>__________________________________
<br>Do you Yahoo!?
<br>Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
<br><a href="http://calendar.yahoo.com">http://calendar.yahoo.com</a>
<p>-------------------------------------------------------
<br>This SF.NET email is sponsored by: eBay
<br>Great deals on office technology -- on eBay now! Click here:
<br><a href="http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5">http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5</a>
<br>_______________________________________________
<br>Valgrind-users mailing list
<br>Val...@li...
<br><a href="https://lists.sourceforge.net/lists/listinfo/valgrind-users">https://lists.sourceforge.net/lists/listinfo/valgrind-users</a></blockquote>

<pre>--&nbsp;
Alex G. Ivershen&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Inet Technologies, Inc.
Network Products Dept.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1500 N. Greenville Ave.
Inet Technologies Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Richardson, TX 75081
Phone: +1-469-330-4295&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; USA

"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd&nbsp;
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music." -- Kristian Wilson, Nintendo, Inc</pre>
&nbsp;</html>

[Valgrind-users] --gen-suppressions prompting

[Leonard m. <spa...@ya...>]

I really like the new capability, ...except for all the prompting.

What do you think of a --gen-suppressions={yes|no|ask} option.  "yes"
would generate suppressions without a prompt for every flagged issue,
and "ask" would do what yes does now.  I just want it to dump
everything in a file and when it prompts me I have to sit there and
bang "y" on the keyboard.

A less desirable second choice would be to add another option to the
prompt.  Currently we have "no this time", "yes this time", and 
"no this time and for all future occurances".  A "yes this time and for
all future occurances" would do it, but you'd still need to 
answer that first prompt, even if you'd routed the valgrind output to a
file.

Thanks,

Randall


__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com

[Valgrind-users] Is there a way to make uninitialised data warnings display as soon as it is moved?

[Joshua Moore-O. <jo...@ch...>]

Just an addon to this post.

On June 11, 2003 11:33 am, Leonard mckinley wrote:
> > validity is checked when a value is:
> > 1. used in a condition (affects control flow)
> > 2. used by a syscall
>
> Ok, thanks.  I see the rational.  When debugging someone else's code
> it does make it a little more challenging to find the root of the
> problem if uninitialized data is moved around a bit before use, but
> so far it's not been too bad.
>
> Randall
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
> http://calendar.yahoo.com
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by: eBay
> Great deals on office technology -- on eBay now! Click here:
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

[Valgrind-users] Re: Question about uninitialized references

[Leonard m. <spa...@ya...>]

> validity is checked when a value is:
> 1. used in a condition (affects control flow)
> 2. used by a syscall

Ok, thanks.  I see the rational.  When debugging someone else's code
it does make it a little more challenging to find the root of the
problem if uninitialized data is moved around a bit before use, but 
so far it's not been too bad.

Randall


__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com

Re: [Valgrind-users] [NRR] RedHat 8.0 pthread "problem"

[Dan K. <da...@ke...>]

Beau D. Simensen wrote:
>>I have to ask -- why are you using threads here?
>>What you've described would work well, and would
>>scale better, using nonblocking i/o and sys_epoll...
> 
> [NRR] - I wanna answer 'cus I think I can get some good input from some of
> ya'll, but this response post really isn't valgrind related.
> 
> The short answer? Because I was unable to find a good reference to base my
> code off of? =) As I said, I'm more of a Perl guy, and I have never really
> done much with sockets before either.   ...
 > [description of daemon acting as both client and server, issuing and
 >  serving both long and short requests]
> To be honest, I really can't even begin to imagine how to do this without
> threads, and I certainly can't imagine it being easier to implement and
> manage any other way. But I'm new... =) *any* help on this would be greatly
> appreciated though. If I saw a great reference as to how someone is doing
> something similar w/o threads, I might just jump on it.

You can most definitely do this all without threads, but it's a big
change in how you think about things.  Worse, if you have to do
anything like disk I/O or use a subroutine library somebody else
wrote that uses blocking I/O, getting away from threads is even harder.

One of these days, I hope somebody publishes a few good examples of
how to do the kind of complex system you're talking about using
nonblocking I/O.  I've written several such systems, but haven't had
the time to document the kind of framework you need.  The closest I've
come so far is to write http://www.kegel.com/c10k.html.

Getting back to valgrind and thread problems, I have a reverse Heisenbug in OpenOffice
under valgrind.  If I run openoffice under gdb and do a File/Save As,
it aborts when I press the first keystroke of a filename.  The stack
traceback is from select(), which seems odd, and there are no threads.  Hmm.
If I run under valgrind, no such problem; File/Save As works fine.
I wonder if this is because I'm running on a dual-processor machine,
and the problem is a clash between threads.
Since valgrind causes all the threads to run on the same simulated cpu,
it can't really observe that whole class of bugs.  You don't happen
to be on a dual processor machine, do you?
- Dan


-- 
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

Re: [Valgrind-users] RedHat 8.0 pthread "problem"

[Olly B. <ol...@su...>]

On Wed, Jun 11, 2003 at 02:08:36AM -0700, Beau D. Simensen wrote:
>   valgrind src/.libs/testsd
>      [<binary> shows me debug info for my code, but threads are broken]

Running valgrind on src/.libs/testsd or src/.libs/lt-testsd works in
some cases, but not others.

It's more reliable to use:

libtool --mode=execute valgrind src/testsd

This lets libtool take care of any messing around with environmental
variables and the like that is required to get the program to run
before it has been installed.

The only wrinkle is that --mode=execute seems to have problems with
passing arguments to valgrind or the program in libtool 1.4.2 (you can
set VALGRIND_OPTS to pass options to valgrind).  I've had no such
problems with libtool 1.5.

Cheers,
    Olly

Re: [Valgrind-users] RedHat 8.0 pthread "problem"

[Beau D. S. <sim...@ha...>]

>
> > Now, this works outside of valgrind. Pretty well -- I haven't noticed
> > any problems with it and other memory debugging stuff seems to think it
> > is OK [for the most part]. I can actually make it "work" in valgrind,
> > but only if I have --trace-pthread=all set. However, this dumps far too
> > much info to be useful for me as I have *alot* of mutex
> > locking/unlocking.
>
> First of all, it's not so unusual for a threaded program to work
> differently under Valgrind;  lots of threaded programs have bugs that
> happen to be "compatible" with the threading implementation they're
> developed on, but break under other threading implementations.
>

OK. I read up on the FAQs, and it didn't sound like that. I guess I know
better now.


>
> However, the fact that it works with --trace-pthread=yes is very strange,
> because --trace-pthread just causes a whole lot of pthread debugging info
> to be printed.  I just looked through all the places where --trace-pthread
> has an effect, every one of them just prints something to stderr (or
> wherever stderr has been redirected to).
>

Strange, yes. If I hadn't found this little quirk, I probably would have
wandered on and tried to find another debugging application. However, seeing
it work when flags were set a particular way gave me hope that valgrind
might work out for me....


>
> So I have no idea.  The only thing I can think of trying is this:  look
> for everywhere that --trace-pthread has an effect in Valgrind's code...
> all instances are in coregrind/vg_scheduler.c, and look very much like
> this:
>
>    if (VG_(clo_trace_pthread_level) >= 2) {        // or ">= 1"
>       VG_(sprintf)(msg_buf, "something...");
>       print_pthread_event(tid, msg_buf);
>    }
>
> Try commenting out the body of all of these if-statements, and see if you
> still get differing behaviour with --trace-pthread=none/some/all.  That
> would at least determine if the actual printing is somehow making it work
> ok...
>

I commented out all of the statements that dealt with
clo_trace_pthread_level. And it was broken. [read: --trace-pthread=all
didn't "work" anymore] So I guess that it is somehow related to printing vs.
not printing. Tiny timing issues introduced by printing maybe?

There was some other stuff I left out, and I'm feeling a bit foolish now.
I'm working in an automake/autoconf project. In doing these changes and
preparing to run the stuff a few way sto see if it made a difference, I
realized I was doing some stuff I hadn't mentioned in my first email. In the
end I see the same results, but there is more stuff between point A and
point F than I let on to begin with.

The "binaries" I was running off of were not actually binaries. They were
the automake magic scripts. :-/ As the little working applications are
actually just shell scripts, running valgrind on my build would only show me
info for the shell script. So I've been running --trace-children=yes so that
I could get info [I assume] on my actual code running as well as the shell
script/other applications.

Trying to make sure I didn't just do something stupid [i.e., maybe it all
worked, just not through the magic scripts], I ran the actual pre-install
binary through valgrind as well. It seems to behave as src/testsd, but I
don't need to --trace-chilren=yes ... which is how I described the problem
to begin with (just --trace-pthread=all, not --trace-children=yes
and --trace-pthread=all).

  valgrind src/testsd
     [<shell wrapper> works!!! but I guess it only checks the shell script?]

  valgrind --trace-children=yes src/testsd
     [<shell wrapper> shows me more debug info, including stuff from my
code, but threads are broken]

  valgrind --trace-pthread=all --trace-children=yes src/testsd
     [<shell wrapper> works, but spews a whole lot of mutex locking stuff]

  valgrind src/.libs/testsd
     [<binary> shows me debug info for my code, but threads are broken]

  valgrind --trace-pthread=all src/.libs/testsd
     [<binary> works, but spews a whole lot of mutex locking stuff]


It really doesn't change the behaviour any, but it is a little different
from what I described before. I just wanted to clarify. FWIW, I also did the
following:


  # rebuild from 'scratc'
  ./bootstrap && ./configure --prefix=/home/altern8/dummy && make
install-strip

  valgrind /home/altern8/dummy/bin/testsd
     [<binary> shows me debug info for my code, but is broken]

  valgrind --trace-pthread=all /home/altern8/dummy/bin/testsd
     [<binary> works, but spews a whole lot of mutex locking stuff]


This way I am pretty sure that it is actually doing what it says it should
be doing. [read: deffinitely no automake/autoconf magic anywhere.] And it
still behaves the same way as I described before.

Hopefully this provides some hints?

I'm really happy that this list has been so helpful so far. Quick responses
and such. Very cool and greatly appreciated!

Thanks again,


Beau D. Simensen
http://www.halogen.org/

Re: [Valgrind-users] [NRR] RedHat 8.0 pthread "problem"

[Beau D. S. <sim...@ha...>]

> >  o Main thread loops, checking a list of remote request handlers to see
> > if one of them needs to be queued up for a client [most of them are
> > scheduled based on time, some of them based on other criteria]. If a
> > request handler is ready to be executed, it pushes a request onto one of
> > two client connection queues.
> >
> >  o Two client connection threads wait for new requests to show up in
> > their queues. When one is found, a connection is opened if one isn't
> > already opened, the request is sent to the server, and the response is
> > read. Connection closes after X number of seconds that the connection
> > hasn't been used.

> I have to ask -- why are you using threads here?
> What you've described would work well, and would
> scale better, using nonblocking i/o and sys_epoll...
> - Dan

[NRR] - I wanna answer 'cus I think I can get some good input from some of
ya'll, but this response post really isn't valgrind related.

The short answer? Because I was unable to find a good reference to base my
code off of? =) As I said, I'm more of a Perl guy, and I have never really
done much with sockets before either. [didn't mention that the first time
around, d'oh]

Longer answer?

There are going to be some queries that I know are going to take 5-35
seconds. During that time, I may be required to make some
as-close-to-realtime-as-possible requests to the application server. So I
figured I'd just send all of the "short" requests through one connection and
send all "long" requests through another. This way, I can be assured that an
urgent request will be able to get through to the application server sooner
rather than waiting for a 20 second request to be finished.

Remember, this is a client. The application server end [not where I'm having
the problem] is handled by X number of fork()ed processes and [IIRC] uses
select.

Maybe there is a way to do these two clients with nonblocking IO? If you
have any good references for how to accomplish something like this, I'd be
very happy to have a look at them. Most of the references I found were on
how to handle multiple inbound connections from a server standpoint, not
multiple outbound connections from a client standpoint.

Even longer answer?

The other part of the application [that I haven't talked about yet] is a few
inbound connection listeners that will accept connections (TCP and UNIX
sockets) and "do stuff." It is not just a client, but a server as well.
Which is why I need to be able to pass on requests as fast as possible out
the "short" application server client thread, even if there is a long
request already in process. [I have all of the server stuff disabled right
now -- the core is finished, but I wanted to cleanup the client stuff before
I moved on to that....]

I threaded it because I wanted to localize each group of processes and not
manage everything at once in one place.


[daemon client] --,
[daemon client] --+----> [(daemon)] =======> [application server]
[daemon client] --'

Daemon is the application in question. It needs to make periodic/scheduled
requests to an application server. It needs to handle incoming requests from
daemon clients. Based on various things [including daemon client requests],
daemon may need to make one-off requests of the application server that need
to respond quickly.

To be honest, I really can't even begin to imagine how to do this without
threads, and I certainly can't imagine it being easier to implement and
manage any other way. But I'm new... =) *any* help on this would be greatly
appreciated though. If I saw a great reference as to how someone is doing
something similar w/o threads, I might just jump on it.


Thanks!


Beau D. Simensen
http://www.halogen.org/

Re: [Valgrind-users] RedHat 8.0 pthread "problem"

[Nicholas N. <nj...@ca...>]

On Wed, 11 Jun 2003, Beau D. Simensen wrote:

> Now, this works outside of valgrind. Pretty well -- I haven't noticed
> any problems with it and other memory debugging stuff seems to think it
> is OK [for the most part]. I can actually make it "work" in valgrind,
> but only if I have --trace-pthread=all set. However, this dumps far too
> much info to be useful for me as I have *alot* of mutex
> locking/unlocking.

First of all, it's not so unusual for a threaded program to work
differently under Valgrind;  lots of threaded programs have bugs that
happen to be "compatible" with the threading implementation they're
developed on, but break under other threading implementations.

However, the fact that it works with --trace-pthread=yes is very strange,
because --trace-pthread just causes a whole lot of pthread debugging info
to be printed.  I just looked through all the places where --trace-pthread
has an effect, every one of them just prints something to stderr (or
wherever stderr has been redirected to).

So I have no idea.  The only thing I can think of trying is this:  look
for everywhere that --trace-pthread has an effect in Valgrind's code...
all instances are in coregrind/vg_scheduler.c, and look very much like
this:

   if (VG_(clo_trace_pthread_level) >= 2) {        // or ">= 1"
      VG_(sprintf)(msg_buf, "something...");
      print_pthread_event(tid, msg_buf);
   }

Try commenting out the body of all of these if-statements, and see if you
still get differing behaviour with --trace-pthread=none/some/all.  That
would at least determine if the actual printing is somehow making it work
ok...

N