Date: Sun, 16 Jan 1994 18:25:58 +0100 From: Stefan Eckart 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 #include 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