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 `/'
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.
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.
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
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.