The exampleapp segfaults whilst running boinc_finish(0), to be precise inside
xml_escape (in=0x0,
out=0xffffbe8c "\350\276\377\377 \305\377\377(\300\377\377n8\346\367\242\037\364\367\060.000000", len=2048)
acoording to gdb

Has anyone any suggestions?

It seems the implementation of a string object allows it to return NULL when requesting the cstring equivalent, which consequently caused the application to crash.

However I'm now bumping into the next cstring problem inside the boinc library, it seems it is a bad thing to clear an already empty string, can anyone with a better understanding of the internals of libc++ comment on this?

Latest tests seem to indicate that somehow during cleanup something goes horribly wrong, has anyone experienced such a failure, which ends up in a call to __exchange_and_add() with an invalid address?

I'm using the boinc VM 40r0 running on VMWare Player on a host system containing x86_64 ubuntu 9.04.

Ok, the following program also fails in exactly the same way:

#include <boinc_api.h>

int main()
{
boinc_init(0);
return 0;
}

Again it seems to have trouble when running the destructors for the APP_INIT_DATA object en it's contained PROXY_INFO object:

GDB stacktrace:
#0 0xb7f26bc9 in __gnu_cxx::__exchange_and_add () from /usr/lib/libstdc++.so.6
#1 0x0805693c in ~PROXY_INFO (this=0x80648d4)
at /usr/include/c++/4.1.3/bits/basic_string.h:232
#2 0x0804e654 in ~APP_INIT_DATA (this=0x8063400) at app_ipc.cpp:60
#3 0xb7cfaab9 in exit () from /lib/i686/cmov/libc.so.6
#4 0xb7ce245d in __libc_start_main () from /lib/i686/cmov/libc.so.6
#5 0x0804a431 in _start ()

Some deeper digging exposes a MEMSET!! on the APP_INIT_DATA object in question (aid). this seems to change the string implementation used by g++'s fields into bogus, which on its turn causes the app to crash. Can anyone confirm they are having this problem to. (check is whether the strings _M_dataplus._M_p field == NULL). I'll post diffs here for anyone interested soon.

EDIT:

Here they are:

lib/app_ipc.cpp:

73,114d72
< void APP_INIT_DATA::clear()
< {
<     major_version = 0;
<     minor_version = 0;
<     release = 0;
<     app_version = 0;
<     memset(app_name, 0, sizeof(app_name));
<     memset(symstore, 0, sizeof(symstore));
<     memset(acct_mgr_url, 0, sizeof(acct_mgr_url));
<     project_preferences = NULL;
<     hostid = 0;
<     memset(user_name, 0, sizeof(user_name));
<     memset(team_name, 0, sizeof(team_name));
<     memset(project_dir, 0, sizeof(project_dir));
<     memset(boinc_dir, 0, sizeof(boinc_dir));
<     memset(wu_name, 0, sizeof(wu_name));
<     memset(authenticator, 0, sizeof(authenticator));
<     slot = 0;
<     user_total_credit = 0.0;
<     user_expavg_credit = 0.0;
<     host_total_credit = 0.0;
<     host_expavg_credit = 0.0;
<     resource_share_fraction = 0.0;
<     memset(&host_info, 0, sizeof(host_info));
<     proxy_info.clear();
<     memset(&global_prefs, 0, sizeof(global_prefs));
<     starting_elapsed_time = 0.0;
< 
<     rsc_fpops_est = 0.0;
<     rsc_fpops_bound = 0.0;
<     rsc_memory_bound = 0.0;
<     rsc_disk_bound = 0.0;
<     computation_deadline = 0.0;
< 
<     fraction_done_start = 0.0;
<     fraction_done_end = 0.0;
< 
<     checkpoint_period = 0.0;
<     memset(&shmem_seg_name, 0, sizeof(shmem_seg_name));
<     wu_cpu_time = 0.0;
< }
< 
274,275c232
<     //memset(&ai, 0, sizeof(ai));
<     ai.clear();
---
>     memset(&ai, 0, sizeof(ai));

lib/app_ipc.h

197,198d196
<     void clear();                         // Have a reliable mechanism for
<                                           // clearing all the info inside

api/boinc_api.cpp:

580,581c580
<     //memset(&aid, 0, sizeof(aid));
<     aid.clear();
---
>     memset(&aid, 0, sizeof(aid));

Hope there usefull to someone

Some deeper digging exposes a MEMSET!! on the APP_INIT_DATA object in question (aid)...

Replacement code for the MEMSET was added at changeset [trac]changeset:20191[/trac], and a second instance was corrected at changeset [trac]changeset:20199[/trac].