Date:	Sun, 16 Jan 1994 18:25:58 +0100
From:	Stefan Eckart <S_Eckart AT lis DOT e-technik DOT tu-muenchen DOT de>
To:	djgpp AT sun DOT soe DOT clarkson DOT edu
Subject:	-pg profiling bug

The following program generates a segmentation violation when run
after being compiled with the -pg option:

/*- test.c ----------------------------*/
#include <stdlib.h>
#include <stdio.h>

main()
{
  unsigned char *p;
  FILE *fd;

  p=(unsigned char *)malloc(400000);
  fd=fopen("testfile","rb");
  printf("0x%08x 0x%08x\n",p,fd);
  fread(p,1,400000,fd);
  fclose(fd);
}
/*-------------------------------------*/

  gcc -pg -o test test.c
  coff2exe test
  test
  symify test

produces the following output (the first line is printf's output):

0x0000a004 0x00004138
Segmentation violation in pointer 0x1b036702 at d8:1248
eax=2b036702 ebx=00000006 ecx=0000007d edx=e002591f esi=0002592b edi=0008b410
ebp=7ffffe10 esp=7ffffdaa cs=d8 ds=38 es=48 fs=48 gs=38 ss=48 cr2=00006702
Call frame traceback EIPs:
  0x00001248   __exit+162
  0x00001a26   _fread+66
  0x000014d5   _main+97

Looking into the code with edebug32 shows the opcode at 0x1248 to be the
incw (%eax) in mcount_isr in crt0.s. (For some reason the value in eax
(2b036702) differs from the pointer value causing the segmentation fault
(0x1b036702)). Anyway, the EIP value read from the stack seems to be far
beyond the code range and therefore mcount_histogram is indexed above its
allocated size. What could be the reason for this to happen? I don't know
enough about go32's internals to figure out the cause for this strange
behaviour.

Some additional information:

- go32 reports:

go32 version 1.11.maint1 Copyright (C) 1993 DJ Delorie
Lowest version I can run is 1.08
go32.exe usage: go32 [-d {debugger}] [{program} [{options} . . . ]]
go32.exe build time was Thu Dec 16 19:07:56 1993
XMS memory available: 2236 Kb
Swap space available: 1048 Kb

- I'm using gcc 2.5.7, 386DX, 4 MB RAM, MSDOS 5.0, HIMEM.SYS, DOS=HIGH,
  1 MB RAMDRIVE in XMS memory, no EMS emulator, no DPMI.

- Without -pg no segmentation violation occurs.

- Replacing the dynamically allocated array with a static one results in
  zero time entries in the gprof report but the segmentation violation
  vanishes.

- The seg. fault occurs in most runs but not always, the dumped register
  values and stack traces are the same each time the error happens.

- The file being read (testfile) is 405504 bytes, thus no EOF condition.

Anything else I forgot to mention?

I'd really like to switch to version 1.11, but without working profiling
feature I have to live with 1.10 :-(

Thanks,

Stefan.
--
stefan AT lis DOT e-technik DOT tu-muenchen DOT de

- Raw text -