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.
--
http://linuxfromscratch.org/mailman/
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
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
other filesystem checks in that function.
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
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 to
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.
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
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
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 filesyst
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
r
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:
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
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
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 sys
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
r
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 y
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 al
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,
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 w
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 f
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
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 you are able to rep
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]>
--
http://l
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.
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 backtr
Greg Schafer wrote:
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
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
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
> 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?
Yeah, but da
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",
Greg Schafer wrote:
Last one wins. In other words, on the GCC command line, switches that come
after override any that come before. The above will achieve the desired
result. I'm sure this is documented somewhere but I cannot find the
reference right now :-/
Thanks, that's what I thought but wa
Jeremy Huntwork wrote:
> [EMAIL PROTECTED] wrote:
>> -sed -i 's/-O2/-O/' MCONFIG
>> +sed -i 's/-O2/-O/' configure
>
> Just for the sake of thoroughness, here... Please note that the above
> sed does *not* remove the use of '-O2' from the compile arguments.
>
> Here's a sample line from one of
[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:
Correct the util-linux segfault fix
-sed -i 's/-O2/-O/' MCONFIG
+sed -i 's
33 matches
Mail list logo
