Bugzilla – Bug 218
Probable mmap() bug that breaks cpp-3.2
Last modified: 2003-02-25 13:18:01 CST
If this is a userspace bug, what version of the package are you using: The problem occurs in the user space, but I am not certain where it comes from (it's not a crash) What kernel are you using: orion:qmake$ uname -a Linux orion 2.4.20-xfs #4 Sun Feb 9 18:07:50 EET 2003 i686 unknown Where did the XFS code come from? (CVS, Linus, your distribution, etc): I'm using CVS HEAD from SGI. Description of Problem: Problem is that cpp-3.2 will malfunct when using XFS. It has been suggested that there might be a problem with mmap() in XFS, not properly null-padding mmap() and that might indeed be the case.... Here is a typical manifestation of the problem: /home-aux/exa/code/kde/qt-copy/include/qcstring.h:394: parse error before `/' token In that source code 394 is the last line and there is no such character as '/' So if I inspect closely and run just the preprocessor: g++-3.2 -E .... g++-3.2: Internal error: Segmentation fault (program cpp0) Please submit a full bug report Now, it might seem that this is a GCC bug, but that isn't the case. When I try to compile the same code on tmpfs or ext2 everything works fine. How Reproducible: You will hate me for this :) It's very reproducible but it might be hard for you to find a test system. The bug pertains to version 2:2.95.4-17 of gcc packages in debian (other versions might not manifest this bug) I have been able to spot the problem only in compilation of Qt from qt-copy in KDE CVS. I think trying to compile Qt 3.1 will be a good start. I've tried other sources I have to reproduce the bug in a minimal setting but so far I have failed. If I can find an easier test case I will send the details. Of course, I would like to hear from you what else I can do to locate the bug or reproduce it in alternative ways. Additional Information: Here is my qt configuration if needed: export YACC='byacc -d' make -f Makefile.cvs ./configure -system-zlib -qt-gif -system-libpng -system-libjpeg \ -plugin-imgfmt-mng -thread -no-stl -no-xinerama -no-g++-exceptions \ -fast -platform linux-g++-i686 Here linux-g++-i686 is standard g++ configuration with some optimization flags and using g++-3.2....
Ugh, almost certainly this is my fault. There was just some reworking of this path. I must have missed something - I did run some tests cases of load which used to break CC. Can you run the mapcheck program (sent seperately) on the filesystem where this happens and let me know the result?
Since I trust you guys, I just ran mapcheck --all after I saw that it detected some errors. It fixed in excess of 20000 errors. Maybe you should be including the tool and documenting this bug in the distro. I guess I'm not the only one with this obscure problem. My file system now seems to work properly. Although it reported 37 errors as well, there doesn't seem to be any major failure. What are those errors anyway?
This appears to have been a case of a filesystem setup while the mapcheck bug was present. Since running mapcheck on the machine there has been no-reoccurence.