Hi Danny,
Le 25/06/2014 15:05, Danny Auble a écrit :
Thanks Rémi. This patch does appear good, but the real question is
where did the
l=0xb0 for file_opts->wckey_list come from. This appears to represent
memory corruption, but it is unclear how.
After few breakpoints and step-by-step debugging session, gdb gave me
the answer: xfree(file_opts) in _destroy_sacctmgr_file_opts().
Once the second option without '=' is detected in _parse_options(), the
if (file_opts->name) branch is taken and _destroy_sacctmgr_file_opts()
is called for the first time with this file_opts struct:
(gdb) n
226 if (file_opts->wckey_list) {
(gdb) p *file_opts
$8 = {admin = SLURMDB_ADMIN_NOTSET, classification = 0, coord_list =
0x0, def_acct = 0x0, ... , qos_list = 0x0, wckey_list = 0x0}
(gdb) n
230 xfree(file_opts);
(gdb) p *file_opts
$9 = {admin = SLURMDB_ADMIN_NOTSET, classification = 0, coord_list =
0x0, def_acct = 0x0, ... , qos_list = 0x0, wckey_list = 0x0}
(gdb) n
232 }
(gdb) p *file_opts
Cannot access memory at address 0x0
Then, when back in _parse_options():
(gdb) n
_parse_options (options=0x7ffffff7e98a
"name1:name2:Description='none':Organization='none':Fairshare=1\n") at
file_functions.c:292
292 break;
(gdb) p *file_opts
$10 = {admin = 4147285656, classification = 32767, coord_list = 0x0,
def_acct = 0x0, ... , qos_list = 0x0, wckey_list = 0xb0}
^^
The structure pointed by file_opts has been free'd in _destroy() but the
pointer in _parse_options() still refer to this memory space. The
pointer should be set to NULL right after _destroy() to avoid extra
reference to this free'd memory.
Then, at the end _parse_options(), the second call to _destroy() is done
with a pointer to unknown garbage.
What do you think?
I couldn't tell if this behaviour is due to my specific combination of
compiler, architecture, (and whatever) though.
