#494 Writing to full disk causes abend on Linux

v4.1
closed
5
2012-08-14
2008-02-09
No

Just ran across the following problem (I first had it on 3.1.x and then upgraded to 3.2.0): when writing my stream class output to a disk that is full, I get a double free error from glibc. I am using the following short test program to write on my external hdd that happened to fill up in the meantime:

/ /
out = .Stream~New("/exthdd/backup3/chmp5b/writetest.txt")
out~Open("Write Replace")
out~LineOut("Hallo")
out~Close

and then get the following error on my openSuSE 10.2 system:

glibc detected rexx: double free or corruption (top): 0x0804baf0 ***
======= Backtrace: =========
/lib/libc.so.6[0xb7c156e1]
/lib/libc.so.6(cfree+0x89)[0xb7c16d79]
/lib/libc.so.6(fclose+0x136)[0xb7c06646]
/opt/ooRexx/lib/ooRexx/librexx.so.3(Z12close_streamP10RexxObjectP11Stream_Info+0xd4)[0xb7f2d264]
/opt/ooRexx/lib/ooRexx/librexx.so.3(_Z14stream_close_mP10RexxObjectPv+0x50)[0xb7f31430]
/opt/ooRexx/lib/ooRexx/librexx.so.3(stream_close+0x36)[0xb7f314d6]
/opt/ooRexx/lib/ooRexx/librexx.so.3(_ZN20RexxNativeActivation3runEjPP10RexxObject+0x31b)[0xb7f1978b]
/opt/ooRexx/lib/ooRexx/librexx.so.3(_ZN10RexxMethod3runEP12RexxActivityP10RexxObjectP10RexxStringjPS3
+0x21d)[0xb7ea424d]
/opt/ooRexx/lib/ooRexx/librexx.so.3(ZN10RexxObject11messageSendEP10RexxStringlPPS+0xa6)[0xb7eae1d6]
/opt/ooRexx/lib/ooRexx/librexx.so.3(ZN22RexxInstructionMessage7executeEP14RexxActivationP19RexxExpressionStack+0x30d)[0xb7ed428d]
/opt/ooRexx/lib/ooRexx/librexx.so.3(_ZN14RexxActivation3runEPP10RexxObjectjP15RexxInstruction+0x5f6)[0xb7f00dd6]
/opt/ooRexx/lib/ooRexx/librexx.so.3(_ZN10RexxMethod4callEP12RexxActivityP10RexxObjectP10RexxStringPS3_jS5_S5_m+0x209)[0xb7ea4969]
/opt/ooRexx/lib/ooRexx/librexx.so.3(_ZN10RexxObject9shriekRunEP10RexxMethodP10RexxStringS3_PPS_j+0x76)[0xb7eaf856]
/opt/ooRexx/lib/ooRexx/librexx.so.3(_Z13SysRunProgramPv+0x31f)[0xb7ef0aaf]
/opt/ooRexx/lib/ooRexx/librexx.so.3(_ZN9RexxLocal10runProgramEP11RexxInteger+0x20)[0xb7f172f0]
/opt/ooRexx/lib/ooRexx/librexx.so.3(_ZN10RexxMethod3runEP12RexxActivityP10RexxObjectP10RexxStringjPS3
+0x55b)[0xb7ea458b]
/opt/ooRexx/lib/ooRexx/librexx.so.3(ZN10RexxObject11messageSendEP10RexxStringlPPS+0xa6)[0xb7eae1d6]
/opt/ooRexx/lib/ooRexx/librexx.so.3(RexxSendMessage+0x3af)[0xb7f0937f]
/opt/ooRexx/lib/ooRexx/librexx.so.3(RexxStart+0xa3)[0xb7ef0df3]
rexx(gxx_personality_v0+0x235)[0x8048961]
/lib/libc.so.6(
libc_start_main+0xdc)[0xb7bc6f9c]
rexx(__gxx_personality_v0+0x35)[0x8048761]
======= Memory map: ========
08048000-08049000 r-xp 00000000 09:01 17190945 /opt/ooRexx/bin/rexx
08049000-0804a000 rw-p 00000000 09:01 17190945 /opt/ooRexx/bin/rexx
0804a000-0806b000 rw-p 0804a000 00:00 0 [heap]
b7600000-b7621000 rw-p b7600000 00:00 0
b7621000-b7700000 ---p b7621000 00:00 0
b7779000-b7b7a000 rw-p b7779000 00:00 0
b7b7a000-b7baf000 r--s 00000000 09:01 59028661 /var/run/nscd/passwd
b7baf000-b7bb1000 rw-p b7baf000 00:00 0
b7bb1000-b7cd9000 r-xp 00000000 09:01 41946373 /lib/libc-2.5.so
b7cd9000-b7cda000 r--p 00128000 09:01 41946373 /lib/libc-2.5.so
b7cda000-b7cdc000 rw-p 00129000 09:01 41946373 /lib/libc-2.5.so
b7cdc000-b7cdf000 rw-p b7cdc000 00:00 0
b7cdf000-b7ce9000 r-xp 00000000 09:01 41949190 /lib/libgcc_s.so.1
b7ce9000-b7ceb000 rw-p 00009000 09:01 41949190 /lib/libgcc_s.so.1
b7ceb000-b7d0f000 r-xp 00000000 09:01 42113166 /lib/libm-2.5.so
b7d0f000-b7d11000 rw-p 00023000 09:01 42113166 /lib/libm-2.5.so
b7d11000-b7dea000 r-xp 00000000 09:01 58729991 /usr/lib/libstdc++.so.6.0.8
b7dea000-b7ded000 r--p 000d9000 09:01 58729991 /usr/lib/libstdc++.so.6.0.8
b7ded000-b7def000 rw-p 000dc000 09:01 58729991 /usr/lib/libstdc++.so.6.0.8
b7def000-b7df6000 rw-p b7def000 00:00 0
b7df6000-b7e0a000 r-xp 00000000 09:01 41946399 /lib/libpthread-2.5.so
b7e0a000-b7e0c000 rw-p 00013000 09:01 41946399 /lib/libpthread-2.5.so
b7e0c000-b7e0e000 rw-p b7e0c000 00:00 0
b7e0e000-b7e10000 r-xp 00000000 09:01 42113164 /lib/libdl-2.5.so
b7e10000-b7e12000 rw-p 00001000 09:01 42113164 /lib/libdl-2.5.so
b7e2d000-b7e39000 r-xp 00000000 09:01 29416983 /opt/ooRexx/lib/ooRexx/librexxapi.so.3.0.4
b7e39000-b7e3a000 rw-p 0000b000 09:01 29416983 /opt/ooRexx/lib/ooRexx/librexxapi.so.3.0.4
b7e3a000-b7e3b000 rw-p b7e3a000 00:00 0
b7e3b000-b7f57000 r-xp 00000000 09:01 29416979 /opt/ooRexx/lib/ooRexx/librexx.so.3.0.4
b7f57000-b7f65000 rw-p 0011b000 09:01 29416979 /opt/ooRexx/lib/ooRexx/librexx.so.3.0.4
b7f65000-b7f6a000 rw-p b7f65000 00:00 0
b7f6a000-b7f6b000 r-xp b7f6a000 00:00 0 [vdso]
b7f6b000-b7f86000 r-xp 00000000 09:01 42010683 /lib/ld-2.5.so
b7f86000-b7f88000 rw-p 0001a000 09:01 42010683 /lib/ld-2.5.so
bfeda000-bfeef000 rw-p bfeda000 00:00 0 [stack]
Aborted

Let me know if you need more information.

Greetings from Germany,
Christian

Discussion

  • Mark Miesfeld

    Mark Miesfeld - 2010-08-12

    First off, sorry it took so long to give you a reply.

    I can not reproduce this at all in the current code base. Here is what I did: I mounted a small file system. In one session I started a small program to gradually fill up the disk. In another session, when the disk go close to being full, I continously ran a small rex script based on what you posted.

    I repeated this a number of times and never saw a problem. I then mounted a USB flash disk that was almost full and repeated the test a couple of times. Still no problem.

    • The stream class from 3.1.2 and 3.2.0 has been completely rewritten. If the bug was in the stream code, that code no longer exists, and there does not appear to be this bug in the current stream code.

    • If the bug was in some other portion of the interpreter, well the entire interpreter has been refactored, and the bug does not show up for me.

    • It seems that you could reproduce the bug easily because you say you upgraded to 3.2.0 and the bug was stil there.

    Becasue of all that, I'm going to mark the bug as out of date and put it in pending. If you can still reproduce this under the 4.0.1 release then reopen the bug and give me the details on how to reproduce it. I promise, I'll look at it right away. <grin>

    Here is some output from my tests:

    root@svdcdemo3:/mnt/tmp# df -h
    Filesystem Size Used Avail Use% Mounted on
    /dev/sda1 36G 15G 19G 45% /
    udev 498M 272K 497M 1% /dev
    none 498M 12K 498M 1% /dev/shm
    none 498M 116K 498M 1% /var/run
    none 498M 0 498M 0% /var/lock
    none 498M 0 498M 0% /lib/init/rw
    /dev/loop0 15M 9.2M 5.4M 64% /mnt/tmp
    root@svdcdemo3:/mnt/tmp# df -h
    Filesystem Size Used Avail Use% Mounted on
    /dev/sda1 36G 15G 19G 45% /
    udev 498M 272K 497M 1% /dev
    none 498M 12K 498M 1% /dev/shm
    none 498M 116K 498M 1% /var/run
    none 498M 0 498M 0% /var/lock
    none 498M 0 498M 0% /lib/init/rw
    /dev/loop0 15M 14M 848K 95% /mnt/tmp
    root@svdcdemo3:/mnt/tmp# ./testFull.rex
    root@svdcdemo3:/mnt/tmp# ./testFull.rex
    root@svdcdemo3:/mnt/tmp# ./testFull.rex
    root@svdcdemo3:/mnt/tmp# ./testFull.rex
    root@svdcdemo3:/mnt/tmp# ./testFull.rex
    root@svdcdemo3:/mnt/tmp# df -h
    Filesystem Size Used Avail Use% Mounted on
    /dev/sda1 36G 15G 19G 45% /
    udev 498M 272K 497M 1% /dev
    none 498M 12K 498M 1% /dev/shm
    none 498M 116K 498M 1% /var/run
    none 498M 0 498M 0% /var/lock
    none 498M 0 498M 0% /lib/init/rw
    /dev/loop0 15M 15M 0 100% /mnt/tmp
    root@svdcdemo3:/mnt/tmp# ll writeTest.txt
    -rw------- 1 root root 0 2010-08-12 13:27 writeTest.txt
    root@svdcdemo3:/mnt/tmp#

     
  • Mark Miesfeld

    Mark Miesfeld - 2010-09-09

    For this bug, I'm leaving the resolution as out of date, changing status to open, and leaving group to v4.0.2. This will signal that I want to test it under the 4.1.0 build. If the test passes, then I will follow through and close it.

     
  • Mark Miesfeld

    Mark Miesfeld - 2010-10-28

    I can not reproduce this problem using 4.1.0 under Kubuntu. I'm going to mark it as 'out of date' and pending for 4.1.0.

    Christian, when the beta starts for 4.1.0 starts, please test this. If you can reproduce it, then mark it as open again and give me the steps to produce the problem.

     
  • Mark Miesfeld

    Mark Miesfeld - 2010-12-05

    The fix for this item was in the 4.1.0 release.

     


Anonymous

Cancel  Add attachments





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

Sign up for the SourceForge newsletter:





No, thanks