Logging via StdErr (or something like it)

Logging via StdErr (or something like it)

Is there a way to enable logging during execution on the servers? Can we write to stderr?

The program runs fine on my local computer, but it crashes during benchmarking and all I got is a stack trace with this message:
invalid submission -> *** glibc detected *** ./run: double free or corruption (!prev)

Thank you in advance!

10 posts / 0 nouveau(x)
Dernière contribution
Reportez-vous à notre Notice d'optimisation pour plus d'informations sur les choix et l'optimisation des performances dans les produits logiciels Intel.

Can't help you with stderr, but:

The "double free" in our context practically means that more than one thread tries to free a pointer.
Just think. Is there a a pointer variable, or even better function call parameter that YOU THINK that is implicitly private, while the compiler maybe doesn't? Go and add an explicit private on that.

Or else, to debug, comment out all free() and add them back one at a time.

As for not happening in your system, well just the problem with debuging parallel. Just be happy that you caught the bug now ;)

Testing parallel programs via outputing to stdout / stderr (by printf or cout) is not reliable, as the additional latency introduced by those instructions might make the error disappear. Your best bet is to isloate the instruction(s) which cause this by commenting and uncommenting blocks of code.

As for the error itself, it might not be as obvious as a simple new / delete allocation problem. There's a lot of allocating behind the scenes in C++, involving copy constructors and destructors. Try to search for this particular error on C++ forums and you might get pointers on what to look for.

Best Reply

Quoting andreib
Is there a way to enable logging during execution on the servers? Can we write to stderr?

You can use "cerr << "Hello World\n";" to write to the standard error output. This will then show up in the benchmark report.

As to the "double free or corruption" error, I used to get the same error. It was caused by the C++ string implementation not being thread-safe. I solved the problem by using c strings (i.e. plain char pointers).

Thank you all for your help :)
I will try to solve the bug using your advice.


I can confirm the problem regarding c++ strings. Hence a solution would be const char* refSeqPtr = refSeq.c_str(); and accesing using refSeqPtr[i] instead of refSeq[i] + modifications in all places where this applies. Optimisations don't go into handling these aspects apparently due to the risk involved in altering data.One more interesting aspect is that on E-350 (dual core) and A8-3650 (quad core) code works just fine with string objects, in "stress testing mode".

Is there a problem with my code or with the servers?
Writing to cerr does not work and I only get this:

error on a 12-cores machine :
invalid submission: unexpected error during runtime.

no details, no stacktrace, nothing :(

Did you have this problem, too?


Sounds like a segmentation fault. Have you tried testing your code locally, on 2 or more cores?

From my brief experience with the benchmarking system, it provides little feedback regarding the result of the tests. So even if you do write to stderr, the output will probably not be forwarded to you in the email.

Here is your error:
ERROR : invalid submission -> *** glibc detected *** ./run: double free or corruption (!prev): 0x0000000001814b30 ***
======= Backtrace: =========

But it seems you corrected it last night.

Laisser un commentaire

Veuillez ouvrir une session pour ajouter un commentaire. Pas encore membre ? Rejoignez-nous dès aujourd’hui