This suggests that the call to vsnprintf is likely to be in your source code, rather than something automatically added by the compiler.
If your source code is under Linux, you should be able to grep for all references to vsnprintf within a whole directory of source code.
If the number of references is small but not zero, it shouldn't take long to add some debugging output to show what will be sent to each call to vsnprintf just before it is called.
One of these web pages says that vsnprintf is new for C++11; I've found nothing on whether the Windows Vista version of msvcrt.dll supports C++11.
I still have the gravity wave application enabled for Albert@Home on my Windows Vista computer, so it can test any new version of this application.
Currently 64 Win applications don't give proper stackdumps, which AFAIK is a limitation of the compiler we use.
I'll try to manually resolve the addresses to something useful.
The error most likely happens in BOINC API code, one of the hundred or so s(n)printf being called with a NULL buffer, format string or string argument. BOINC doesn't do a lot of error-checking.
I don't know for sure yet, but some time later it might help if you could capture a init_data.xml file from the slot directory of such a task on your system and make it available to me.
Hello. There was a problem with task h1_0991.65_S6Directed__S6CasAf40a_992.8Hz_186_1
After 90, 909 % completing, it was going to close cycle (as I understand) because in few hours it was that 90, 909 % and no more. So I aborted it.
A number of Einstein apps display infrequent progress, eventually it would have reached 100%, and may even have spent some time at 100%, if you'd had more patience.
It has not failed but has a very strange behavior, it has ran for more than 10mins and is using only 6% of one core (calculation time is 50 secs after almost 15mn of duration).
In the stderr.txt I see :
Quote:
2014-09-03 22:40:38.9239 (79813) [debug]: Flags: LAL_NDEBUG, OPTIMIZE, HS_OPTIMIZATION, GC_SSE2_OPT, X64, SSE, SSE2, GNUC X86 GNUX86
2014-09-03 22:40:38.9261 (79813) [debug]: Set up communication with graphics process.
Code-version: %% LAL: 6.10.0.1 (CLEAN a8f4bc45afff592cb0b364305d838a3e4674209f)
%% LALApps: 6.12.0.1 (CLEAN a8f4bc45afff592cb0b364305d838a3e4674209f)
2014-09-03 22:40:39.2324 (79813) [normal]: Reading input data ...
So it's been "reading input data" for more than 10mn ?
edit : it seems I was too eager to have action, now things are much better :
I found some documentation on
)
I found some documentation on vsnprintf:
http://www.cplusplus.com/reference/cstdio/vsnprintf/
http://linux.about.com/library/cmd/blcmdl3_vsnprintf.htm
http://www.tin.org/bin/man.cgi?section=3&topic=vsnprintf
http://www.delorie.com/djgpp/doc/libc/libc_855.html
http://en.cppreference.com/w/cpp/io/c/vfprintf
http://pubs.opengroup.org/onlinepubs/9699919799/functions/vfprintf.html
http://stackoverflow.com/questions/3362994/vsnprintf-and-gcc
This suggests that the call to vsnprintf is likely to be in your source code, rather than something automatically added by the compiler.
If your source code is under Linux, you should be able to grep for all references to vsnprintf within a whole directory of source code.
If the number of references is small but not zero, it shouldn't take long to add some debugging output to show what will be sent to each call to vsnprintf just before it is called.
One of these web pages says that vsnprintf is new for C++11; I've found nothing on whether the Windows Vista version of msvcrt.dll supports C++11.
I still have the gravity wave application enabled for Albert@Home on my Windows Vista computer, so it can test any new version of this application.
Currently 64 Win applications
)
Currently 64 Win applications don't give proper stackdumps, which AFAIK is a limitation of the compiler we use.
I'll try to manually resolve the addresses to something useful.
The error most likely happens in BOINC API code, one of the hundred or so s(n)printf being called with a NULL buffer, format string or string argument. BOINC doesn't do a lot of error-checking.
I don't know for sure yet, but some time later it might help if you could capture a init_data.xml file from the slot directory of such a task on your system and make it available to me.
BM
BM
Sorry, haven't been paying
)
Sorry, haven't been paying attention to my system, just noticed that some recent CasA tasks have thrown an exception, here is an example:
http://einsteinathome.org/task/451810894
Seems they don't like boinc version 7.4.12, will upgrade to 7.4.18 and see if they continue to fail, if I get any more tasks.
Hello. There was a problem
)
Hello. There was a problem with task h1_0991.65_S6Directed__S6CasAf40a_992.8Hz_186_1
After 90, 909 % completing, it was going to close cycle (as I understand) because in few hours it was that 90, 909 % and no more. So I aborted it.
RE: Hello. There was a
)
A number of Einstein apps display infrequent progress, eventually it would have reached 100%, and may even have spent some time at 100%, if you'd had more patience.
Claggy
Hello I have one such WU
)
Hello
I have one such WU on my Mac (intel) : http://einsteinathome.org/task/452691711
It has not failed but has a very strange behavior, it has ran for more than 10mins and is using only 6% of one core (calculation time is 50 secs after almost 15mn of duration).
In the stderr.txt I see :
So it's been "reading input data" for more than 10mn ?
edit : it seems I was too eager to have action, now things are much better :
And CPU is fully used, so there is "long reading input data" step in the app, ok :)
Sorry for useless post !