On Sun, 04 Sep 2005 10:31:02 +1000, Greg Schafer wrote:
Jürg Billeter wrote:
The patch speaks for itself,
BTW, changing the problematic line to:
read(fd, reiserfsb, sizeof(reiserfsb)) == sizeof(reiserfsb)
seems to also fix the problem. It's simpler and is more in line with the
William Harrington([EMAIL PROTECTED])@Mon, Sep 12, 2005 at 03:30:11PM -0500:
On Sun, 04 Sep 2005 10:31:02 +1000, Greg Schafer wrote:
J?rg Billeter wrote:
Works fine out of the box.
Works for me also,but still needs the cramfs patch though.
--
On Sam, 2005-09-03 at 10:35 +1000, Greg Schafer wrote:
Better still, we should just find the bug and fix it. Why pessimize the
whole of Util-linux just because of an intermittent bug in cfdisk? It's a
bad workaround IMHO. Surely someone who is able to reproduce the crash can
obtain a backtrace
On Fre, 2005-09-02 at 20:04 -0400, Jeremy Huntwork wrote:
[EMAIL PROTECTED] wrote:
Author: matthew
Date: 2005-09-02 16:01:00 -0600 (Fri, 02 Sep 2005)
New Revision: 6800
Modified:
branches/gcc4/BOOK/chapter01/changelog.xml
branches/gcc4/BOOK/chapter06/util-linux.xml
Log:
On Sam, 2005-09-03 at 08:24 +0200, Jürg Billeter wrote:
Maybe it wouldn't be that unwise to test with current 4.0 (or maybe also
4.1) snapshot as it may already have been fixed. Will test that
4.0-20050901 and 4.1-20050902 are still affected.
--
Jürg Billeter [EMAIL PROTECTED]
--
On Sam, 2005-09-03 at 08:24 +0200, Jürg Billeter wrote:
On Sam, 2005-09-03 at 10:35 +1000, Greg Schafer wrote:
Better still, we should just find the bug and fix it. Why pessimize the
whole of Util-linux just because of an intermittent bug in cfdisk? It's a
bad workaround IMHO. Surely
On Sat, 03 Sep 2005 10:37:30 +0200, Jürg Billeter wrote:
Ok, it's not a gcc bug at all... The SEGV seems to have destroyed some
debug info on the stack and that's the reason gdb didn't help. The
problem occured on all systems with linux partitions that don't have a
ext2/ext3, xfs, or jfs
On Sam, 2005-09-03 at 18:53 +1000, Greg Schafer wrote:
On Sat, 03 Sep 2005 10:37:30 +0200, Jürg Billeter wrote:
Ok, it's not a gcc bug at all... The SEGV seems to have destroyed some
debug info on the stack and that's the reason gdb didn't help. The
problem occured on all systems with
Jürg Billeter wrote:
The patch speaks for itself, I have no idea why this doesn't crash
with other gcc versions / optimization settings, must be luck...
The attached script should pinpoint the particular setting that tickles
the crash, in case you're really interested in finding out! IIRC,
Jürg Billeter wrote:
On Sam, 2005-09-03 at 18:53 +1000, Greg Schafer wrote:
On Sat, 03 Sep 2005 10:37:30 +0200, Jürg Billeter wrote:
Ok, it's not a gcc bug at all... The SEGV seems to have destroyed some
debug info on the stack and that's the reason gdb didn't help. The
problem occured on
Greg Schafer wrote:
Jürg Billeter wrote:
It's not as easy as it sounds. As it's very likely that it's a GCC
optimization bug you can't really debug the compiled cfdisk as the
generated code is wrong. The stack after the SEGV is completely
destroyed, gdb doesn't help at all.
It seems as if
Jürg Billeter wrote:
Ok, it's not a gcc bug at all... The SEGV seems to have destroyed some
debug info on the stack and that's the reason gdb didn't help. The
problem occured on all systems with linux partitions that don't have a
ext2/ext3, xfs, or jfs filesystem as the crash happens during the
On Sam, 2005-09-03 at 05:26 -0400, Chris Staub wrote:
On Sat, 03 Sep 2005 10:37:30 +0200, Jürg Billeter wrote:
Ok, it's not a gcc bug at all... The SEGV seems to have destroyed some
debug info on the stack and that's the reason gdb didn't help. The
problem occured on all systems with linux
Chris Staub wrote:
Jürg Billeter wrote:
On Sam, 2005-09-03 at 18:53 +1000, Greg Schafer wrote:
On Sat, 03 Sep 2005 10:37:30 +0200, Jürg Billeter wrote:
Ok, it's not a gcc bug at all... The SEGV seems to have destroyed some
debug info on the stack and that's the reason gdb didn't help. The
Chris Staub wrote:
Jürg Billeter wrote:
On Sam, 2005-09-03 at 05:26 -0400, Chris Staub wrote:
On Sat, 03 Sep 2005 10:37:30 +0200, Jürg Billeter wrote:
Ok, it's not a gcc bug at all... The SEGV seems to have destroyed
some
debug info on the stack and that's the reason gdb didn't help. The
Jürg Billeter wrote:
Ok, it's not a gcc bug at all... The SEGV seems to have destroyed some
debug info on the stack and that's the reason gdb didn't help. The
problem occured on all systems with linux partitions that don't have a
ext2/ext3, xfs, or jfs filesystem as the crash happens during the
Jeremy Huntwork wrote:
Jürg Billeter wrote:
Ok, it's not a gcc bug at all... The SEGV seems to have destroyed some
debug info on the stack and that's the reason gdb didn't help. The
problem occured on all systems with linux partitions that don't have a
ext2/ext3, xfs, or jfs filesystem as
Greg Schafer wrote:
very often. So in summary, if type 83 partitions exist and they have
reiserfs OR if they don't have any filesystem on them whatsoever, the
problematic code path is taken and the crash is likely to occur. Hope
this makes sense.
Yes, very much. Thanks. And of course, now that
Jürg Billeter wrote:
The patch speaks for itself,
BTW, changing the problematic line to:
read(fd, reiserfsb, sizeof(reiserfsb)) == sizeof(reiserfsb)
seems to also fix the problem. It's simpler and is more in line with the
other filesystem checks in that function. Maybe the above variant is
On Sat, Sep 03, 2005 at 08:24:23PM -0400, Jeremy Huntwork wrote:
Greg Schafer wrote:
very often. So in summary, if type 83 partitions exist and they have
reiserfs OR if they don't have any filesystem on them whatsoever, the
problematic code path is taken and the crash is likely to occur. Hope
Archaic wrote:
Even though this bug seems to be tickled by gcc-4, would it be prudent
to add this to trunk as well since it's running the same version of
util-linux?
Well, does anyone have a recent build of trunk with a reiser* partition?
Perhaps we could check to see if cfdisk bombs there
On Sat, Sep 03, 2005 at 08:36:40PM -0400, Jeremy Huntwork wrote:
Well, does anyone have a recent build of trunk with a reiser* partition?
Perhaps we could check to see if cfdisk bombs there too? Anyway,
recalling Matt's previous email, gcc4 was slated to move to trunk in a
matter of a
Jeremy Huntwork wrote:
Indeed. I don't have a lot of time (or even any debugging tools
installed atm) so I haven't had a chance to do that yet. But it does
seem a better course to take if we can spot the exact problem.
Hrm. Does this spark anything with anyone?
--
JH
execve(./fdisk/cfdisk,
Jeremy Huntwork wrote:
I'm only guessing here, but..
read(3, \353H\220\320\274\0|\373P\7P\37\374\276\33|\277\33\6PW..., 512) =
512
ioctl(3, 0x301, 0xbfd12110) = 0
It seems the above is a read of the 1st 512 bytes of /dev/hda ie: the MBR.
The next few reads appears to be the
Greg Schafer wrote:
_llseek(3, 1028225536, [1028225536], SEEK_SET) = 0
read(3, ReIsEr4\0\0\0\0\0\0\0\0\0\0\0\0\20\2725\3511\237\246M\204...,
1024) = 1024
Here is a completely untested patch. Someone wanna try it? It's based on
previous problems we had with sfdisk and GCC-3.4.x
It's a long
25 matches
Mail list logo
