#1466 rm -rf coredumps

MSYS (75)

msys: MINGW32_NT-6.0 KHELDAR 1.0.15(0.47/3/2) 2010-07-06 22:04 i686 Msys
bash: 3.1.17(1)-release (i686-pc-msys)
coreutils: 5.97-3

mkdir /usr/tmp/abc
touch /usr/tmp/def
rm -rf /usr/tmp/abc
0 [main] rm 26596 open_stackdumpfile: Dumping stack trace to rm.exe.stackdump
Segmentation fault (core dumped)

sounds like MSYS is getting confused by the / == /usr and /tmp == %TMP% mounts. What IS /usr/tmp? Physically, it is located at C:\msys\1.0\tmp -- but the logic here is a little twisted. If *I'm* getting confused, it's possible msys is confused -- maybe hits an infloop and runs out of either buffer space (constructing the win32 path) or stack space? Just a guess...


  • Cesar Strauss

    Cesar Strauss - 2010-09-17
    • assigned_to: nobody --> cstrauss
    • status: open --> closed-fixed
  • Cesar Strauss

    Cesar Strauss - 2010-09-17

    Thanks for the report. I fixed this in MSYS CVS.

    The issue with MSYS was an unnecessary round-trip between native- and POSIX-land, like:

    /usr/tmp/abc -> C:\msys\1.0\tmp\abc -> /tmp/abc -> %TMP%/abc

    This was helped by / being earlier than /usr in the mount table (actually, the order was undefined).

    It actually triggered a bug in rm, which didn't handle properly the NULL value incorrectly returned from MSYS opendir. Since the bad code path in rm isn't triggered anymore since I fixed MSYS, I left it alone. Anyway, the code in question was completely rewritten in coreutils HEAD, so maybe it will be no longer be an issue once we upgrade eventually.


Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks