Discussion:
[ast-developers] String based stream freed twice
Dr. Werner Fink
2014-04-14 07:27:03 UTC
Permalink
Hi,

this is what valgrind shows

==23137== Invalid read of size 2
==23137== at 0x57DB446: stkclose (stk.c:312)
==23137== by 0x511CB6A: sh_funstaks (parse.c:495)
==23137== by 0x511CB99: sh_freeup (parse.c:476)
==23137== by 0x5139567: sh_eval_20120720 (xec.c:4202)
==23137== by 0x50C75C0: b_dot_cmd (misc.c:295)
==23137== by 0x5138B54: sh_exec (xec.c:1382)
==23137== by 0x50D4956: exfile (main.c:627)
==23137== by 0x50D52D9: sh_main (main.c:399)
==23137== by 0x5F17C15: (below main) (in /lib64/libc-2.11.3.so)
==23137== Address 0x62f3430 is 224 bytes inside a block of size 248 free'd
==23137== at 0x4C2852A: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==23137== by 0x57DBC44: stkexcept (stk.c:182)
==23137== by 0x582CCF0: sfraise (sfraise.c:90)
==23137== by 0x5812C48: sfclose (sfclose.c:160)
==23137== by 0x5113BAC: _nv_unset (name.c:2639)
==23137== by 0x50CF10F: unall (typeset.c:1285)
==23137== by 0x5138B54: sh_exec (xec.c:1382)
==23137== by 0x513346C: sh_exec (xec.c:2255)
==23137== by 0x5139409: sh_eval_20120720 (xec.c:4189)
==23137== by 0x50C75C0: b_dot_cmd (misc.c:295)
==23137== by 0x5138B54: sh_exec (xec.c:1382)
==23137== by 0x50D4956: exfile (main.c:627)

that is that in sh_eval_20120720() witin the while loop the stream is
freed by sh_exec() -> unall() -> _nv_unset() -> sfclose()
and later on after the loop with sh_freeup() -> sh_funstaks() -> stkclose()

Werner
--
"Having a smoking section in a restaurant is like having
a peeing section in a swimming pool." -- Edward Burr
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.research.att.com/pipermail/ast-developers/attachments/20140414/a680459a/attachment.sig>
David Korn
2014-04-14 14:21:59 UTC
Permalink
Does this happen after applying the patch you sent?
Post by Dr. Werner Fink
Hi,
this is what valgrind shows
==23137== Invalid read of size 2
==23137== at 0x57DB446: stkclose (stk.c:312)
==23137== by 0x511CB6A: sh_funstaks (parse.c:495)
==23137== by 0x511CB99: sh_freeup (parse.c:476)
==23137== by 0x5139567: sh_eval_20120720 (xec.c:4202)
==23137== by 0x50C75C0: b_dot_cmd (misc.c:295)
==23137== by 0x5138B54: sh_exec (xec.c:1382)
==23137== by 0x50D4956: exfile (main.c:627)
==23137== by 0x50D52D9: sh_main (main.c:399)
==23137== by 0x5F17C15: (below main) (in /lib64/libc-2.11.3.so)
==23137== Address 0x62f3430 is 224 bytes inside a block of size 248 free'd
==23137== at 0x4C2852A: free (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==23137== by 0x57DBC44: stkexcept (stk.c:182)
==23137== by 0x582CCF0: sfraise (sfraise.c:90)
==23137== by 0x5812C48: sfclose (sfclose.c:160)
==23137== by 0x5113BAC: _nv_unset (name.c:2639)
==23137== by 0x50CF10F: unall (typeset.c:1285)
==23137== by 0x5138B54: sh_exec (xec.c:1382)
==23137== by 0x513346C: sh_exec (xec.c:2255)
==23137== by 0x5139409: sh_eval_20120720 (xec.c:4189)
==23137== by 0x50C75C0: b_dot_cmd (misc.c:295)
==23137== by 0x5138B54: sh_exec (xec.c:1382)
==23137== by 0x50D4956: exfile (main.c:627)
that is that in sh_eval_20120720() witin the while loop the stream is
freed by sh_exec() -> unall() -> _nv_unset() -> sfclose()
and later on after the loop with sh_freeup() -> sh_funstaks() -> stkclose()
Werner
--
"Having a smoking section in a restaurant is like having
a peeing section in a swimming pool." -- Edward Burr
_______________________________________________
ast-developers mailing list
ast-developers at lists.research.att.com
http://lists.research.att.com/mailman/listinfo/ast-developers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.research.att.com/pipermail/ast-developers/attachments/20140414/149864e7/attachment.html>
Dr. Werner Fink
2014-04-14 15:46:14 UTC
Permalink
Post by David Korn
Does this happen after applying the patch you sent?
Indeed ... but I've seen a similar crash before ... now I've modified the
patch to avoid both this crash and also the crash without the patch.

Compare with attached patch. Here I set

slp->slptr = 0

after it has been closed in _nv_unset() and check for a valid slptr
in sh_funstaks().

If this is wrong then please show me how to avoid those invalid reads
on already freed data. I've several users around here which indeed
see this with their scripts even with the default _AST_std_malloc==0

Now one remaining problem is the !(flags&NV_ARRAY) in nv_create() that is
without ksh crashes with comvar.sh and builtin_poll.sh ... with this
change the crash for comvar.sh is gone but then builtin_poll.sh does
crash on an other place

#0 0x000000000043d5ab in nv_create (name=0x7efd70 "pl[16388]", root=0x7f2f20, flags=132608, dp=0x7fff71569e60)
at /usr/src/packages/BUILD/ksh93/src/cmd/ksh93/sh/name.c:1222
1222 if(ap && ap->table && tp)

Beside this I see always that io.sh from the test suite chrashes
with shcomp on a SIGPIPE.

Also sometime the signal.sh hangs in a futex() which indicates that
memory was allocated within a signal handler.
Post by David Korn
Post by Dr. Werner Fink
Hi,
this is what valgrind shows
==23137== Invalid read of size 2
==23137== at 0x57DB446: stkclose (stk.c:312)
==23137== by 0x511CB6A: sh_funstaks (parse.c:495)
==23137== by 0x511CB99: sh_freeup (parse.c:476)
==23137== by 0x5139567: sh_eval_20120720 (xec.c:4202)
==23137== by 0x50C75C0: b_dot_cmd (misc.c:295)
==23137== by 0x5138B54: sh_exec (xec.c:1382)
==23137== by 0x50D4956: exfile (main.c:627)
==23137== by 0x50D52D9: sh_main (main.c:399)
==23137== by 0x5F17C15: (below main) (in /lib64/libc-2.11.3.so)
==23137== Address 0x62f3430 is 224 bytes inside a block of size 248 free'd
==23137== at 0x4C2852A: free (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==23137== by 0x57DBC44: stkexcept (stk.c:182)
==23137== by 0x582CCF0: sfraise (sfraise.c:90)
==23137== by 0x5812C48: sfclose (sfclose.c:160)
==23137== by 0x5113BAC: _nv_unset (name.c:2639)
==23137== by 0x50CF10F: unall (typeset.c:1285)
==23137== by 0x5138B54: sh_exec (xec.c:1382)
==23137== by 0x513346C: sh_exec (xec.c:2255)
==23137== by 0x5139409: sh_eval_20120720 (xec.c:4189)
==23137== by 0x50C75C0: b_dot_cmd (misc.c:295)
==23137== by 0x5138B54: sh_exec (xec.c:1382)
==23137== by 0x50D4956: exfile (main.c:627)
that is that in sh_eval_20120720() witin the while loop the stream is
freed by sh_exec() -> unall() -> _nv_unset() -> sfclose()
and later on after the loop with sh_freeup() -> sh_funstaks() -> stkclose()
--
"Having a smoking section in a restaurant is like having
a peeing section in a swimming pool." -- Edward Burr
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ksh93-crashes.dif
Type: text/x-patch
Size: 3263 bytes
Desc: not available
URL: <http://lists.research.att.com/pipermail/ast-developers/attachments/20140414/67f01928/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.research.att.com/pipermail/ast-developers/attachments/20140414/67f01928/attachment-0001.sig>
Dr. Werner Fink
2014-04-14 16:18:06 UTC
Permalink
Post by Dr. Werner Fink
Now one remaining problem is the !(flags&NV_ARRAY) in nv_create() that is
without ksh crashes with comvar.sh and builtin_poll.sh ... with this
change the crash for comvar.sh is gone but then builtin_poll.sh does
crash on an other place
Please replace comvar.sh with comvario.sh ... comvar.sh works whereas
comvario.sh with the unpatched ksh does stop here

if(mp && mp->nvname==0 || *mp->nvname==0)

in nv_name() as mp=np->nvenv a line above is not valid anymore after
the free in nv_delete().


Werner
--
"Having a smoking section in a restaurant is like having
a peeing section in a swimming pool." -- Edward Burr
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.research.att.com/pipermail/ast-developers/attachments/20140414/18361ce6/attachment.sig>
Dr. Werner Fink
2014-04-15 07:31:45 UTC
Permalink
Post by Dr. Werner Fink
Post by Dr. Werner Fink
Now one remaining problem is the !(flags&NV_ARRAY) in nv_create() that is
without ksh crashes with comvar.sh and builtin_poll.sh ... with this
change the crash for comvar.sh is gone but then builtin_poll.sh does
crash on an other place
Please replace comvar.sh with comvario.sh ... comvar.sh works whereas
comvario.sh with the unpatched ksh does stop here
if(mp && mp->nvname==0 || *mp->nvname==0)
in nv_name() as mp=np->nvenv a line above is not valid anymore after
the free in nv_delete().
For a test I've added reference bit

char nvref:1; /* remember if hold */

in src/cmd/ksh93/include/nval.h for struct Namval, then used

if(np && !nv_isattr(np,NV_MINIMAL) && shp->oldnp && !np->nvenv && shp->oldnp!=np)
+ {
+ shp->oldnp->nvref = 1;
np->nvenv = (char*)shp->oldnp;
+ }


in src/cmd/ksh93/sh/name.c nv_create() to be able to use

- if(!(flags&NV_NOFREE) && ((flags&NV_FUNCTION) || !nv_subsaved(np,flags&NV_TABLE)))
+ if(!np->nvref && !(flags&NV_NOFREE) && ((flags&NV_FUNCTION) || !nv_subsaved(np,flags&NV_TABLE)))
free((void*)np);

in nv_delete() ... it works for comvario.sh, arrays.sh, and arrays2.sh but not for
builtin_poll.sh. In other words the reason was not the !(flags&NV_ARRAY) in
nv_create() instead of using the nvref bit:

src/cmd/ksh93/tests> gdb $X /tmp/test_builtin_poll.lp1I2UEl/core
[...]
Program terminated with signal 11, Segmentation fault.
#0 0x000000000043d5ab in nv_create (name=0x7efd70 "pl[16388]", root=0x7f3150, flags=132608, dp=0x7fff1d357c80)
at /usr/src/packages/BUILD/ksh93/src/cmd/ksh93/sh/name.c:1217
1217 if(ap && ap->table && tp)

The !(flags&NV_ARRAY) method in nv_create() still shows invalid reads but does not
crash whereas the reference bit method shows memory leaks (definitely lost).

For the problem with the stalled signal handlers here from our build system here:

[ 1436s] test signal begins at 2014-04-14+15:31:46
[30238s] qemu: terminating on signal 15 from pid 15707

or

[ 1482s] test signal begins at 2014-04-14+15:32:33
[30289s] qemu: terminating on signal 15 from pid 26509

or

[ 2165s] test signal begins at 2014-04-14+15:44:00
[30976s] qemu: terminating on signal 15 from pid 5588
--
"Having a smoking section in a restaurant is like having
a peeing section in a swimming pool." -- Edward Burr
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.research.att.com/pipermail/ast-developers/attachments/20140415/1ba0ab38/attachment.sig>
Continue reading on narkive:
Loading...