LinuxQuestions.org
Go Job Hunting at the LQ Job Marketplace
Go Back   LinuxQuestions.org > Forums > Non-*NIX Forums > Programming
User Name
Password
Programming This forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.

Notices

Reply
 
Search this Thread
Old 02-20-2013, 04:37 AM   #1
bigearsbilly
Senior Member
 
Registered: Mar 2004
Location: england
Distribution: FreeBSD, Debian, Mint, Puppy
Posts: 3,311

Rep: Reputation: 175Reputation: 175
gprof strace blows up on recv


I am reading data from a remote site, lots of data.

I peek at the data, to see how big the frame is: (16 bytes peek)

Code:
recv(g.socket, buffer, bite, MSG_PEEK | MSG_WAITALL );
I now know the frame size so I can slurp it in: (~ 200 bytes)

Code:
recv(g.socket, buffer, frame_sz, MSG_WAITALL);
Now this works lovely, it runs overnight, 500+ frames a second. No problem.


If I strace it or turn on profiling for gprof
It messes the recv up and I don't read the wire correctly and
I get invalid frames.

Has anyone encountered this before?

Last edited by bigearsbilly; 02-20-2013 at 04:38 AM.
 
Old 02-20-2013, 05:07 AM   #2
linosaurusroot
Member
 
Registered: Oct 2012
Distribution: OpenSuSE,RHEL,Fedora,OpenBSD
Posts: 866
Blog Entries: 2

Rep: Reputation: 215Reputation: 215Reputation: 215
I don't know what this is but it might help to state what s/w you are using including versions.
Was your program compiled on the same system where you run it?
Do all forms of strace have this effect; even if you exclude read() and recv()?

Also before getting excited about possible kernel or library bugs I suggest a further look over the bounds checking of your code in case that includes a problem which behaves differently depending on the way it is called.

Last edited by linosaurusroot; 02-20-2013 at 05:10 AM.
 
Old 02-20-2013, 06:36 AM   #3
bigearsbilly
Senior Member
 
Registered: Mar 2004
Location: england
Distribution: FreeBSD, Debian, Mint, Puppy
Posts: 3,311

Original Poster
Rep: Reputation: 175Reputation: 175
Weirdly it turned out to be this:

Code:
     setsockopt(g.socket, SOL_SOCKET, SO_RCVBUF, &oval, sizeof oval);
Double-checked the arguments, look ok.

Commented out and it's all fine and dandy !?!?!?!?



This is pre-production, all my lib functions are wrapped, return values are checked, logging in place,
buffers are all static and massive guy.

Code:
[billy@sierra:0]$ gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.5-8' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.4 --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.4.5 (Debian 4.4.5-8)


Doesn't seem to go wrong on FreeBSD.
Code:
[billy@elmer:130]$ gcc -v
Using built-in specs.
Target: amd64-undermydesk-freebsd
Configured with: FreeBSD/amd64 system compiler
Thread model: posix
gcc version 4.2.2 20070831 prerelease [FreeBSD]

Last edited by bigearsbilly; 02-20-2013 at 06:39 AM.
 
Old 02-20-2013, 07:59 AM   #4
NevemTeve
Senior Member
 
Registered: Oct 2011
Location: Budapest
Distribution: Debian/GNU/Linux, AIX
Posts: 1,923

Rep: Reputation: 524Reputation: 524Reputation: 524Reputation: 524Reputation: 524Reputation: 524
You seem to ignore the return value of 'recv', which is a very bad idea.
 
Old 02-20-2013, 08:26 AM   #5
bigearsbilly
Senior Member
 
Registered: Mar 2004
Location: england
Distribution: FreeBSD, Debian, Mint, Puppy
Posts: 3,311

Original Poster
Rep: Reputation: 175Reputation: 175
Quote:
Originally Posted by NevemTeve View Post
You seem to ignore the return value of 'recv', which is a very bad idea.
No I don't actually, I just edited for this post.
 
Old 02-20-2013, 08:58 AM   #6
NevemTeve
Senior Member
 
Registered: Oct 2011
Location: Budapest
Distribution: Debian/GNU/Linux, AIX
Posts: 1,923

Rep: Reputation: 524Reputation: 524Reputation: 524Reputation: 524Reputation: 524Reputation: 524
Then paste in the relevant lines -- the handling of 'returned_len < requested_len' case might be wrong.

(A note: this could be easily implemented without MSG_PEEK)

Last edited by NevemTeve; 02-20-2013 at 09:00 AM.
 
Old 02-20-2013, 01:25 PM   #7
bigearsbilly
Senior Member
 
Registered: Mar 2004
Location: england
Distribution: FreeBSD, Debian, Mint, Puppy
Posts: 3,311

Original Poster
Rep: Reputation: 175Reputation: 175
Quote:
Originally Posted by NevemTeve View Post
-- the handling of 'returned_len < requested_len' case might be wrong.

(A note: this could be easily implemented without MSG_PEEK)
there is no such case MSG_WAITALL ensures you get all,
and not as easily as my way.
IMHO ;-)
 
Old 02-20-2013, 01:42 PM   #8
NevemTeve
Senior Member
 
Registered: Oct 2011
Location: Budapest
Distribution: Debian/GNU/Linux, AIX
Posts: 1,923

Rep: Reputation: 524Reputation: 524Reputation: 524Reputation: 524Reputation: 524Reputation: 524
manual:

This flag requests that the operation block until the full request is satisfied. However, the call may still return less data than requested if a signal is caught, an error or disconnect occurs.

Plus: it makes your code linux-specific.
 
Old 02-20-2013, 02:51 PM   #9
bigearsbilly
Senior Member
 
Registered: Mar 2004
Location: england
Distribution: FreeBSD, Debian, Mint, Puppy
Posts: 3,311

Original Poster
Rep: Reputation: 175Reputation: 175
No, MSG_WAITALL MSG_PEEK are not linux specific, I have run it on FreeBSD too.
http://pubs.opengroup.org/onlinepubs...ions/recv.html
They are even mentioned in Steven's UNP.

I don't care (In this specific case) about disconnects, signals or errors, I elect to simply bomb out and attempt to reconnect.

In normal cicumstances it stays on 24 hours a day, I am reading about 500 frames a second
each being written to file, about 800 files. I am using 3% CPU on a 500Mhz 512M virtual debian.
So I reckon I can program a bit

Only get weird reads under gprof on linux, without profiling it's fine.
I think it's likely static/shared library issues with gprof.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Regarding gprof: shekar_08 General 0 12-16-2009 03:17 AM
KAtomic ... well, blows up! chexmix Slackware 6 11-09-2008 08:29 PM
Install program blows up ELPDave Fedora 8 05-02-2007 07:40 AM
KDE 3.2 blows.. subekk0 Slackware 1 02-19-2004 12:51 AM
superblock blows me out of the water dwynter Linux - Hardware 2 10-02-2002 11:37 AM


All times are GMT -5. The time now is 07:58 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration