From: SourceForge.net <no...@so...> - 2010-08-12 21:35:20
|
Bugs item #1890332, was opened at 2008-02-09 13:23 Message generated for change (Comment added) made by miesfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=1890332&group_id=119701 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Interpreter Group: 3.2.0 >Status: Pending >Resolution: Out of Date Priority: 5 Private: No Submitted By: Christian Michel (cmichel) >Assigned to: Mark Miesfeld (miesfeld) Summary: Writing to full disk causes abend on Linux Initial Comment: 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 ---------------------------------------------------------------------- >Comment By: Mark Miesfeld (miesfeld) Date: 2010-08-12 14:35 Message: 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# ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=1890332&group_id=119701 |