Segfault in uppercase sample application during boinc_finish(0)

Message boards : Server programs : Segfault in uppercase sample application during boinc_finish(0)
Message board moderation

To post messages, you must log in.

AuthorMessage
davidv1992

Send message
Joined: 2 Feb 10
Posts: 6
Netherlands
Message 30779 - Posted: 3 Feb 2010, 11:04:59 UTC

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?
ID: 30779 · Report as offensive
davidv1992

Send message
Joined: 2 Feb 10
Posts: 6
Netherlands
Message 30781 - Posted: 3 Feb 2010, 16:30:48 UTC - in response to Message 30779.  

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?
ID: 30781 · Report as offensive
davidv1992

Send message
Joined: 2 Feb 10
Posts: 6
Netherlands
Message 30783 - Posted: 3 Feb 2010, 19:09:36 UTC - in response to Message 30781.  

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.
ID: 30783 · Report as offensive
davidv1992

Send message
Joined: 2 Feb 10
Posts: 6
Netherlands
Message 30790 - Posted: 4 Feb 2010, 8:29:07 UTC - in response to Message 30783.  
Last modified: 4 Feb 2010, 9:18:50 UTC

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
ID: 30790 · Report as offensive
Richard Haselgrove
Volunteer tester
Help desk expert

Send message
Joined: 5 Oct 06
Posts: 5077
United Kingdom
Message 30791 - Posted: 4 Feb 2010, 9:31:05 UTC - in response to Message 30790.  

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].
ID: 30791 · Report as offensive

Message boards : Server programs : Segfault in uppercase sample application during boinc_finish(0)

Copyright © 2024 University of California.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.