Bug#757835: nfs-kernel-server: after update 1.2.8-6->1.2.8-8 rpc.mountd starts crashing
amd64. I think it affects all architectures. In case you want to
follow-up, attached is minimum testcase I could come up with. It
crashes with gcc-4.9 and -O2. No crash with gcc-4.8, or at -O1.
$gcc-4.9 -W -Wall -O2 client.c && ./a.out
Segmentation fault
$gcc-4.8 -W -Wall -O2 client.c && ./a.out
$gcc-4.9 -W -Wall -O1 client.c && ./a.out
$
Petr
On Mon, Aug 11, 2014 at 12:15 PM, Steve Langasek wrote:
> On Mon, Aug 11, 2014 at 11:49:16AM -0700, Petr Vandrovec wrote:
>> Hi,
>> it seems to be gcc bug. For inexplicable reason compiler optimized
>> 'if (cp && *cp)' to just 'if (*cp)' :-(
>
>> Changing 'char *cp' to 'char * volatile cp' at line 468 in
>> support/export/client.c is enough to explain to gcc that it has no
>> idea what it is doing, and fixes the crash.
>
>> I think that after code does 'strncpy(new, old, cp-old)' or
>> 'new[cp-old] = 0' or 'if (cp != old && *cp)' compiler believes 'cp'
>> cannot be NULL, forgetting that both 'cp' and 'old' could have been
>> NULL, making these expressions valid for NULL cp.
>
> Are you seeing this problem on i386 (like the original submitter), or do you
> see this problem on a different architecture?
>
> (If it's a compiler problem, this will be relevant to getting it fixed
> properly.)
>
> --
> Steve Langasek Give me a lever long enough and a Free OS
> Debian Developer to set it on, and I can move the world.
> Ubuntu Developerhttp://www.debian.org/
> slanga...@ubuntu.com vor...@debian.org
char buf[100];
void
add_name(char *old)
{
char *cp = old;
while (cp && *cp) {
cp++;
}
__builtin_strncpy(buf, old, cp-old);
if (cp != old) {
buf[0] = 'Q';
}
if (cp && *cp) {
buf[0] = 'Q';
}
}
int main(void) {
add_name(0);
return 0;
}
Bug#757835: nfs-kernel-server: after update 1.2.8-6->1.2.8-8 rpc.mountd starts crashing
Hi, it seems to be gcc bug. For inexplicable reason compiler optimized 'if (cp && *cp)' to just 'if (*cp)' :-( Changing 'char *cp' to 'char * volatile cp' at line 468 in support/export/client.c is enough to explain to gcc that it has no idea what it is doing, and fixes the crash. I think that after code does 'strncpy(new, old, cp-old)' or 'new[cp-old] = 0' or 'if (cp != old && *cp)' compiler believes 'cp' cannot be NULL, forgetting that both 'cp' and 'old' could have been NULL, making these expressions valid for NULL cp. Petr nfsworkaround.patch Description: Binary data
Bug#311815: matrox support on ppc64
Sven Luther wrote: On Wed, Jan 11, 2006 at 11:26:35PM +0100, Petr Vandrovec wrote: Anyway when I have two reports, one saying that matroxfb does not work on 2.6.11 and another that it does work, I'm lost. As since 2.6.9 or so matroxfb uses only readl()/writel() to access all hardware, without any optimizations, 64bitness of hardware should not matter, only endianness problems should in the drawing code (matroxfb_1bpp_imageblit) - readl & writel should still work same way. Its not the same card though, one is a G450, and the other a G200. Furthermoe Tom used a 2.6.11.6 kernel, while Roberto probably used a much earlier version. Not sure if there are still two different matroxfb in 2.6.11 as they used to be though ? There were never two different matroxfbs in any kernel... Also from matroxfb's viewpoint all accelerators between Millennium I and G550 are identical - if you got some picture on screen and your monitor agrees that input signal is what you've specified, then you should observe identical behavior on primary head. I repeat again, anything older than 2.6.12 is completely uninteresting as 2.6.12 is known to fix problems with character painting on big endian. Petr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#311815: matrox support on ppc64
Tom Gall wrote: Hi Petr, I was just talking to sven luther about matrox graphics on ppc64. It would seem we have somewhat similiar experiences tho somewhat different as well. Currently I'm running 2.6.11.6 on my power3 box with a matrox g200. I do pass to the kernel : video=matroxfb:[EMAIL PROTECTED],memtype:3 . You'll want to do the same if you're not. This does work, console, X and all. Now later kernels, 2.6.15 for instance seem to be quite quite busted but I suspect 2.6.14.x is probably fine, the thought being that 2.6.15 is obviously when the great grand merge was done. matroxfb itself should not have changed between 2.6.12 and 2.6.15 at all. Only difference between 2.6.12 and 2.6.15 are: (1) Removal of hardware cursor. fbcon lost this ability sometime before 2.6.15, so it was removed. (2) matroxfb now knows how to find PInS structure in the GXP450 (or how is IBM adapter named). This should alleviate need for 'memtype:3'. (3) Added PCI IDs for some Matrox Mystique AGP I never ever saw. (4) Different cache flush is used on old 2064W chips (old Millennium I). So as far as I can tell, you should get identical behavior with 2.6.12 and anything newer. It would be nice if you could tell us what color depth you are using (default should be 8bpp, but maybe you did not have built this support into kernel so another depth was used) and character cell size you are using (8x16 or anything else). Anyway when I have two reports, one saying that matroxfb does not work on 2.6.11 and another that it does work, I'm lost. As since 2.6.9 or so matroxfb uses only readl()/writel() to access all hardware, without any optimizations, 64bitness of hardware should not matter, only endianness problems should in the drawing code (matroxfb_1bpp_imageblit) - readl & writel should still work same way. Petr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#311815: powerpc & matroxfb?
Are there some details available about hardware in question? For some time matroxfb drives accelerator in little endian mode. Unfortunately there is no screenshot nor dmesg log, nor used font size, so I can only guess what problem is. To track problem further I need to know what happens with 2.6.12 or newer kernel - some bigendian fixes for accelerated characters drawing went into 2.6.12, so it is quite possible that problem is already fixed. Petr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
