Hello Olivier,
some time ago I sent you a little patch diff for an fflush() on screenf.
I didn't see a notice yet that it was applied. It's always nice knowing
that it's applied or rejected, so at least I can close it from my side.
But that's not the main reason I start this topic, I have two more
questions/remarks on this feature.
1. the difference between the option -trace_screen or not (running in
background).
In the code, I see that the USR2 signal anyhow generates the screen
file, it being already open if -trace_screen is given or otherwise
opening it in append mode. It looks a little bit weird to me to code
this double for the same behaviour, and to keep in one case the file
descriptor open all the time. It would be simpler to just open it when
needed (then my flush() gets obsolete too;-).
Now you might wonder why I'm looking at this so deeply, and I'll try to
describe the bug I triggered on this, although I can't find any problem
in the code explaining it. But it might give someone else a clue to fix
it.
2. -trace_screen option overflowing screen statistics file
I'm normally running sipp in background with "... -bg -trace_screen ..."
and getting some statistics on how it behaves using the USR2 signal.
The software is sipp.2006-11-08 (for completeness with some
modifications in a totally other part, which I'll publish soon),
compiled on a Linux 2.4.26 from Slackware 10.0.0.
I noticed that once I triggered the statistics output to the screen
file, the file kept growing with the last part of the statistics being
repeated over and over again (with a time interval of seconds
magnitude). The part being repeated was not always the same and could be
in the middle of a header line, so it doesn't seem to be the program
code doing this. When I send a new signal, I get again the complete
statistics screen series, and the last part repeating (might be somewhat
different in length).
I didn't find anything in the code + signal handling that could explain
this, so it might be deeper in the standard libs + OS, but for a quite
normal text output to a file, that would surprise me too. Anybody else
seen such things or knows what's wrong?
The only thing I could find maybe not being totally ok, but not
explaining this effect, is that the variable signalDump is not defined
"volatile", but compiler misinterpretation of this would cause the
complete statistics to be repeated, and not part. (I hope this didn't
change from C to C++).
For completeness I should maybe add that I got in an earlier version of
sipp when running on another machine no statistics output at all with
USR2 (with the same executable giving good behaviour on my "normal"
machine, both having same OS).
And then to close this, the work around for now: don't use the
"-trace_screen" option on the command line, the program will anyhow
create the file on receipt of a USR2 signal.
Best regards,
MarcVD
(-: from Marc VAN DIEST (BELGACOM ANS/NTA) +32 2 244 5078 ;-)
**** DISCLAIMER ****
http://www.belgacom.be/maildisclaimer
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Sipp-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sipp-users
