Hi Roland,
Thanks for your interest. We was able to reduce it to a simple script.
1) MALLOCDEBUG info can be found here:
http://www.ibm.com/developerworks/aix/library/au-mallocdebug.html
http://www.ibm.com/developerworks/aix/library/au-mallocdebug.html
2&3) We'll see if we can do this.
4) Any basic wildcards (?, *, [set], or [!set]) file matching will core dump.
# export MALLOCDEBUG=catch_overflow
# /usr/lpp/mmfs/bin/mmksh
# print $KSH_VERSION
Version JM 93t+ 2010-06-21 MM-1302
# ls -l /tmp/foo5
-rw-r--r-- 1 root system 0 May 19 09:58 /tmp/foo5
# ls -l /tmp/foo?
Memory fault(coredump)
Same if runs in script.
# cat /tmp/t
#!/usr/lpp/mmfs/bin/mmksh
print -- /tmp/foo?
exit
# /tmp/t
Memory fault(coredump)
# dbx /usr/lpp/mmfs/bin/mmksh core
Type 'help' for help.
warning: The core file is not a fullcore. Some info may
not be available.
[using memory image in core]
reading symbolic information ...warning: no source compiled with -g
Segmentation fault in readdir64 at 0xd02358dc
0xd02358dc (readdir64+0x9c) 901f0020 stw r0,0x20(r31)
(dbx) where
readdir64(??) at 0xd02358dc
gl_dirnext(0x2ff20dd8, 0x2003afe0) at 0x100d3954
glob_dir(0x2ff20dd8, 0x20035c98) at 0x100d2954
glob.glob(0x20035c89, 0xb850, 0x0, 0x2ff20dd8) at 0x100d34b8
path_expand(0x20035c89, 0x2ff21194) at 0x100d0be4
path_generate(0x0, 0x2ff21194) at 0x100d1258
endfield(0x20030230, 0x0) at 0x100c6b38
sh_macexpand(0x20000de8, 0x20035c68, 0x2ff21194, 0x0) at 0x100cf8ec
arg_expand(0x20000de8, 0x20035c68, 0x2ff21194, 0x0) at 0x100b6478
sh_argbuild(0x20000de8, 0x2ff2124c, 0x20035c38, 0x0) at 0x100b65f8
sh_exec(0x20035c38, 0x4) at 0x100ba9b4
exfile(0x20000de8, 0x20190818, 0xa) at 0x10001568
sh_main(0x2, 0x2ff22430, 0x0) at 0x10002304
pmain.main(0x2, 0x2ff22430) at 0x1000036c
Thanks,
Tru
________________________________
From: Roland Mainz <[email protected]>
To: Truong (Tru) Vu <[email protected]>
Cc: "[email protected]"
<[email protected]>
Sent: Saturday, May 18, 2013 7:10 AM
Subject: Re: [ast-developers] segmenation fault in readdir64
On Fri, May 17, 2013 at 5:56 PM, Truong (Tru) Vu <[email protected]> wrote:
> After turned on MALLOCDEBUG on AIX, GPFS command got core dump. It is
> running with ksh Version JM 93t+ 2010-06-21.
>
> # export MALLOCDEBUG=catch_overflow,validate_ptrs
>
> Segmentation fault in readdir64 at 0xd02358dc
> 0xd02358dc (readdir64+0x9c) 901f0020 stw r0,0x20(r31)
> (dbx) where
> readdir64(??) at 0xd02358dc
> gl_dirnext(0x2ff138d8, 0x2003afe0) at 0x100d3954
> glob_dir(0x2ff138d8, 0x20036380) at 0x100d2954
> glob.glob(0x20036359, 0xb850, 0x0, 0x2ff138d8) at 0x100d34b8
> path_expand(0x20036359, 0x2ff13c94) at 0x100d0be4
> path_generate(0x0, 0x2ff13c94) at 0x100d1258
> endfield(0x200300c8, 0x0) at 0x100c6b38
> sh_macexpand(0x20000de8, 0x2029b5b8, 0x2ff13c94, 0x0) at 0x100cf8ec
> arg_expand(0x20000de8, 0x2029b5b8, 0x2ff13c94, 0x0) at 0x100b6478
> sh_argbuild(0x20000de8, 0x2ff13d4c, 0x2029b598, 0x0) at 0x100b65f8
> sh_exec(0x2029b598, 0x4) at 0x100ba9b4
> sh_exec(0x2029f878, 0x6) at 0x100bd31c
> sh_funscope(0x6, 0x200362ec, 0x0, 0x2ff15ce0, 0x4) at 0x100b9314
> sh_funct(0x20000de8, 0x2031efc0, 0x6, 0x200362ec, 0x0, 0x4) at 0x100b986c
> sh_exec(0x2026a088, 0x4) at 0x100bc0d4
> sh_exec(0x2026b250, 0x7) at 0x100bd31c
> sh_funscope(0x7, 0x20036234, 0x0, 0x2ff17d50, 0x5) at 0x100b9314
> sh_funct(0x20000de8, 0x2031e820, 0x7, 0x20036234, 0x0, 0x5) at 0x100b986c
> sh_exec(0x200360d0, 0x5) at 0x100bc0d4
> sh_subshell(0x200360d0, 0x5, 0x1) at 0x100b2ed8
> comsubst(0x200300c8, 0x200360d0, 0x1) at 0x100c9d7c
> varsub(0x200300c8) at 0x100ca8fc
> copyto(0x200300c8, 0x0, 0x0) at 0x100ce408
> sh_mactrim(0x20000de8, 0x2025f0d9, 0xffffffff) at 0x100cf478
> nv_setlist(0x2025f0d0, 0x20200, 0x0) at 0x10016a2c
> sh_exec(0x2025f1a8, 0x4) at 0x100bb000
> sh_exec(0x2025f208, 0x4) at 0x100bd31c
> sh_exec(0x2025ec30, 0x4) at 0x100bdff0
> sh_exec(0x20260740, 0x7) at 0x100bd31c
> sh_funscope(0x2, 0x20036060, 0x0, 0x2ff1d780, 0x5) at 0x100b9314
> sh_funct(0x20000de8, 0x2031e7c0, 0x2, 0x20036060, 0x0, 0x5) at 0x100b986c
> sh_exec(0x20036018, 0x5) at 0x100bc0d4
> sh_subshell(0x20036018, 0x5, 0x1) at 0x100b2ed8
> comsubst(0x200300c8, 0x20036018, 0x1) at 0x100c9d7c
> varsub(0x200300c8) at 0x100ca8fc
> copyto(0x200300c8, 0x0, 0x0) at 0x100ce408
> sh_mactrim(0x20000de8, 0x20035b61, 0xffffffff) at 0x100cf478
> nv_setlist(0x20035b58, 0x20200, 0x0) at 0x10016a2c
> sh_exec(0x20035b88, 0x4) at 0x100bb000
> sh_exec(0x20035c20, 0x4) at 0x100bd31c
> sh_exec(0x20035ad0, 0x4) at 0x100bdff0
> exfile(0x20000de8, 0x201906a8, 0xa) at 0x10001568
> sh_main(0x2, 0x2ff2240c, 0x0) at 0x10002304
> pmain.main(0x2, 0x2ff2240c) at 0x1000036c
>
> Can you please tell us if this is a known problem and if there is any fix?
Erm... some questions:
1. what exactly does "MALLOCDEBUG" do (it's not in the AST code so I
assume it's for libc-controlled heap debugging in AIX's native libc
(can't verify this myself right now)) ?
2. Can you test whether the issue still occurs with ksh93v- (latest
version can be obtained from
http://www2.research.att.com/sw/download/alpha/) ?
3. Please build the alpha with $ ksh ./bin/package make
PACKAGE_OPTIONS='map-libc' # ... the "map-libc" option moves some of
the functions in libast into a seperate symbol namespace (prefixed
with |_ast_*()|) and check whether the issue is gone then... if this
happens we may have an issue with libc vs. libast symbol clashes
4. We need the script which caused the crash... preferably a "reduced
testcase" which exactly triggers the issue that we can integrate this
into ksh93's test suite...
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) [email protected]
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 3992797
(;O/ \/ \O;)
_______________________________________________
ast-developers mailing list
[email protected]
http://lists.research.att.com/mailman/listinfo/ast-developers
