DragonFlyBSD

On Mon, Jun 19, 2006 at 07:06:40PM +0900, YONETANI Tomokazu wrote:

This seems like another stack-smash-protector bug and still lives
in our compiler, only triggered when you use -O(s|[2-9]) flags AND
-march flag (which defaults to pentiumpro) .

-march or -mcpu? The former is certainly not default and can trigger a
variety of bugs.

If you do one of the following and the problem disappears:
- add fno-stack-smash-protector to CFLAGS
change prefix[] in function FindExec() shown below to a static array
so as there's no char array in the local parameter. char array of
size more than 8 bytes on the stack can trigger the bug.

Well, under 8 byte the stack protection would not be active.

Joerg

On Mon, Jun 19, 2006 at 01:30:51PM +0200, joerg@britannica.bec.de wrote:

On Mon, Jun 19, 2006 at 07:06:40PM +0900, YONETANI Tomokazu wrote:

This seems like another stack-smash-protector bug and still lives
in our compiler, only triggered when you use -O(s|[2-9]) flags AND
-march flag (which defaults to pentiumpro) .

-march or -mcpu? The former is certainly not default and can trigger a
variety of bugs.

Sorry, the default is -mtune, but both -march=pentiumpro and
-mtune=pentiumpro can trigger the bug(and the compiler complained
that -mcpu is deprecated).

If you do one of the following and the problem disappears:
- add fno-stack-smash-protector to CFLAGS
change prefix[] in function FindExec() shown below to a static array
so as there's no char array in the local parameter. char array of
size more than 8 bytes on the stack can trigger the bug.

Well, under 8 byte the stack protection would not be active.

I have almost zero knowledge of how stack protector works, but
does it only care about char array of size greater than 8 bytes
(8 bytes was ok)? I also tried int[] and double[], but none of them
did it.

On Mon, Jun 19, 2006 at 09:13:15PM +0900, YONETANI Tomokazu wrote:

I have almost zero knowledge of how stack protector works, but
does it only care about char array of size greater than 8 bytes
(8 bytes was ok)? I also tried int[] and double[], but none of them
did it.

Hm. Could be a bug in the reordering done for character arrays only.
If you can create a smaller testcase, we can bug Etoh about it :-)

Joerg

On Mon, Jun 19, 2006 at 02:20:36PM +0200, joerg@britannica.bec.de wrote:

On Mon, Jun 19, 2006 at 09:13:15PM +0900, YONETANI Tomokazu wrote:

I have almost zero knowledge of how stack protector works, but
does it only care about char array of size greater than 8 bytes
(8 bytes was ok)? I also tried int[] and double[], but none of them
did it.

Hm. Could be a bug in the reordering done for character arrays only.
If you can create a smaller testcase, we can bug Etoh about it :-)

Done. It's very hard to narrow down when gdb lies to me :)
(attached)

Additional notes:

On Tue, Jun 20, 2006 at 01:20:56AM +0900, YONETANI Tomokazu wrote:

Hm. Could be a bug in the reordering done for character arrays only.
If you can create a smaller testcase, we can bug Etoh about it :-)

Done. It's very hard to narrow down when gdb lies to me :)
(attached)

static int
bar(void *p) {
char baz⁹;
int val = 1;

/* just to quiet gcc, no effects on the result */
(void)baz; (void)val;

Turned out that `val' is not needed, only baz[] with its size > 8bytes
is needed.

if (true_expr && !p)
p = &foo;
if (true_expr && !p)

And if you exchange `true_expr' and `!p' around `&&' in either or both
of if-statement above, the bug is not triggered.

On Mon, Jun 19, 2006 at 02:20:36PM +0200, joerg@britannica.bec.de wrote:

Hm. Could be a bug in the reordering done for character arrays only.
If you can create a smaller testcase, we can bug Etoh about it :-)

Anyone already told him about this problem? If not, please tell me
his email address.

Thanks.

On Tue, Jun 27, 2006 at 04:36:24PM +0900, YONETANI Tomokazu wrote:

On Mon, Jun 19, 2006 at 02:20:36PM +0200, joerg@britannica.bec.de wrote:

Hm. Could be a bug in the reordering done for character arrays only.
If you can create a smaller testcase, we can bug Etoh about it :-)

Anyone already told him about this problem? If not, please tell me
his email address.

I did, but it often takes some time for him to respond.

Joerg

On Tue, Jun 27, 2006 at 01:04:09PM +0200, joerg@britannica.bec.de wrote:

On Tue, Jun 27, 2006 at 04:36:24PM +0900, YONETANI Tomokazu wrote:

On Mon, Jun 19, 2006 at 02:20:36PM +0200, joerg@britannica.bec.de wrote:

Hm. Could be a bug in the reordering done for character arrays only.
If you can create a smaller testcase, we can bug Etoh about it :-)

Anyone already told him about this problem? If not, please tell me
his email address.

I did, but it often takes some time for him to respond.

Thanks, I just wanted to make sure he's been notified :)

Just FYI, the current release version of GCC, 4.1.1, has incorporated
a reimplemented version of SSP and that version doesn't have this bug.

Cheers.

As the default compiler has been switched to gcc4 this doesn't
seem to be important anymore. Do we want to close this one?