Bug 98738 - gcc3.3 (& 3.2) mishandling fstreams.
gcc3.3 (& 3.2) mishandling fstreams.
Product: Red Hat Raw Hide
Classification: Retired
Component: gcc3 (Show other bugs)
xscale Linux
high Severity high
: ---
: ---
Assigned To: Jakub Jelinek
Depends On:
  Show dependency treegraph
Reported: 2003-07-08 06:38 EDT by Kyriakos Sidiropoulos
Modified: 2005-10-31 17:00 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-07-08 11:07:51 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
source and precompiled source (672.92 KB, application/octet-stream)
2003-07-08 06:44 EDT, Kyriakos Sidiropoulos
no flags Details
procompiled source from SUNOS platform with gcc 3.2.2 (340.02 KB, application/octet-stream)
2003-07-08 07:51 EDT, Kyriakos Sidiropoulos
no flags Details

  None (edit)
Description Kyriakos Sidiropoulos 2003-07-08 06:38:03 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830

Description of problem:
Problem with the binary not with the compilation. Happens with gcc3.2 too.
fstream constructors are not treated properly somewhere. All ofstram and
ifstream constructors cause the program to segfault when they are used. These
constructors are located at file: FlowAnalyzer.c++ at lines: 91 to 95.

Version-Release number of selected component (if applicable):
gcc-3.3-12 20030623 (RawHide)

How reproducible:

Steps to Reproduce:
1.Download the sources: nfc.orig.tar.bz2
2.cd nfc && make clean && make
3. ./nfc.out 2003 06 27 --output-directory=./foo/ \
--ip-directory=input/1_IPs_to_search --server-name=olympos-e43 \

Actual Results:  <...>
segmentation fault

Expected Results:  The program shouldn't have crashed at the lines mentioned
above. The streams requested should have opened properly.

Additional info:

1) Used MALLOC_CHECK=2 but didn't know what this does and how to use it.
   The crash remained however.

2) GDB:

    GDB without using Electric Fence:

(gdb) run  2003 06 27 --output-directory=./foo/ \
--ip-directory=input/1_IPs_to_search --server-name=olympos-e43 \
Program received signal SIGSEGV, Segmentation fault.
0x400871f1 in calloc () from /lib/libc.so.6

    With Electric Fence:

make clean && make efence

then run gdb:

(gdb) run 2003 06 27 --output-directory=./foo/ \
--ip-directory=input/1_IPs_to_search --server-name=olympos-e43 \
ElectricFence Aborting: free(bffff794): address not from malloc().

Program received signal SIGILL, Illegal instruction.
[Switching to Thread 8192 (LWP 21159)]
0x4003bd01 in kill () from /lib/libc.so.6

3) Could the above problem have anything to do with that I am using the glibc
provided by RedHat8 and not a more recent version of glibc??
Or is this problem compiler specific?? (libstdc++ or something)

If there is any hint "at hand" on how to workaround this problem, giving it
would be highly appreciated. Thanks and have a day better than mine. :))
Comment 1 Kyriakos Sidiropoulos 2003-07-08 06:44:45 EDT
Created attachment 92792 [details]
source and precompiled source
Comment 2 Kyriakos Sidiropoulos 2003-07-08 07:45:51 EDT
It's interesting the way the problem occurs at an other platform:

bash-2.05$ uname -a
SunOS venus 5.9 Generic_112233-04 sun4u sparc SUNW,Ultra-30

bash-2.05$ gcc --version
gcc (GCC) 3.2.2
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO

bash-2.05$ ls -l /usr/local/lib/libstdc++.so*
lrwxrwxrwx   1 root     other         18 Mar 12 17:07
/usr/local/lib/libstdc++.so -> libstdc++.so.5.0.2
lrwxrwxrwx   1 root     other         18 Mar 12 17:07
/usr/local/lib/libstdc++.so.5 -> libstdc++.so.5.0.2
-rwxr-xr-x   1 bin      bin      8151688 Feb 10 12:22

bash-2.05$ make clean && make

For _this_ platform the problem occurs IF the files I am trying to create do not
exist in the first place. Hence:

bash-2.05$ ( rm ./foo/.* || : ) && ./nfc.out [same params ...]
Abort (core dumped)


BUT if I `touch' these files first to create them manually and then
run `./nfc.out' the problem goes away:

bash-2.05$ ( rm ./foo/.* || : ) && touch
foo/{.AllOfInflow.tmp,.AllOfOutflow.tmp} && ./nfc.out [usual params ...]
(no problem ...)

Hope this proves useful.

Comment 3 Kyriakos Sidiropoulos 2003-07-08 07:51:46 EDT
Created attachment 92793 [details]
procompiled source from SUNOS platform with gcc 3.2.2
Comment 4 Kyriakos Sidiropoulos 2003-07-08 10:57:22 EDT
OK. The one who can give an me an explanation of what goes wrong here (other
than that I am dealing with a bug) is granted permission to shoot me in the
head. Open file: srcs/main.c++. After these lines:

int main( int argc,
	  char * argv[])
  SystemInteraction SysArgs( argc, argv);

Insert this line:

  std::ofstream AllInflowFile( "blah_blah");

Write the file out and: "make clean && make" the program. Now run:

bash # ./nfc.out 2003 06 27 --output-directory=./foo/ \
--ip-directory=input/1_IPs_to_search --server-name=olympos-e43 \

The program will sigsegv as usual uppon the line we inserted above.


Now open file: srcs/SystemInteraction.c++. At the constructor
`SystemInteraction( ...)' delete/comment the line:

"   delete[] argv;"

Now recompile the program the usual way and run it the usual way:

bash # ./nfc.out 2003 06 27 --output-directory=./foo/ \
--ip-directory=input/1_IPs_to_search --server-name=olympos-e43 \

It won't sigsegv at the points it used too.
Comment 5 Jakub Jelinek 2003-07-08 11:07:51 EDT
First of all, bugzilla is not a support forum, it is a place where to report
bugs in the packages shipped in the distribution.
Doing a delete[] argv; on the array passed to main is certainly a fatal bug,
that array is not malloced so cannot be freed.
You either have to make a copy of the array if you wish to free it, or
you cannot free it.
Doing free(3) something that has not been obtained by malloc(3), calloc(3) or
realloc(3) means anything can be broken since then in the allocator data structures,
so any *alloc call or free call later on can crash.

Note You need to log in before you can comment on or make changes to this bug.