ash: massive wildcard expansion hangs up the system

[dmik]

If you check out automake with:

http://svn.netlabs.org/repos/ports/automake/trunk@1006 D:/Coding/ports/automake/trunk

and then run this script called t.sh

ls D:/Coding/ports/automake/trunk/t/ax/*.sh D:/Coding/ports/automake/trunk/t/*.sh D:/Coding/ports/automake/trunk/contrib/t/*.sh 2>/dev/null;

as

sh t.sh

you will get a complete system hang that requires hard reset. This happens both with libc065 and libc066. The binutils version is 2.21-1.oc00.

[dmik]

I guess I know what happens there. The directory D:/Coding/ports/automake/trunk/t/ contains 1312 *.sh files. When sh.exe processes this command, it tries to expand *.sh into command line arguments that it then passes to ls.exe via DosExecPgm. However, the resulting list is actually very big (more than 64K while DosExecPgm is know to only support 32K) and, as a result, sh spits

ls: error 22

22 is EINVAL which most likely means DosExecPgm fails (I saw in perl it recently, see r1006).

If we pass more than that, then somehow sh.exe gets screwed up and hangs up the system. This needs some debugging in sh.exe so I'm renaming this ticket.

[dmik]

Note that if you use cmd.exe to execute this ls command like this:

cmd.exe /c ls D:/Coding/ports/automake/trunk/t/*.sh

then all works because in this case it's kLIBC who does wildcard expansion — within the ls.exe startup sequence before it's main() method is called (and the kLIBC code does that correctly).

[dmik]

It looks like kLIBC is still the guilty one here. Perhaps, wildcard processing code creates a wrong argv array or such. There is a corresponding kLIBC defect. See ​http://trac.netlabs.org/libc/ticket/303#comment:7.

There is no easy way to fix this in ash/dash this other than turn automatic wildcard expansion off (i.e. remove -Zwild-args). May be we should actually do that as a temporary solution. I will try and leave this open for a while.

[dmik]

Removing -Zargs-wild doesn't help here actually. It cures only the top-most invocation of dash.exe itself, but if you pass it a script (t.sh from the example above) it still hangs. Closing this in favor of ​http://trac.netlabs.org/libc/ticket/303 (makes no sense to deal with this problem until that obvious problem is resolved in kLIBC at least).