SIGSEGV before main() is reached (solution and thanks)

SIGSEGV before main() is reached (solution and thanks)

Post by Yee On » Sun, 15 Oct 1995 04:00:00

(If someone else helped me, thanks also to you.)

I'm summarizing what i learned for the benefit of others who
may have this problem.  Naturally experts already know everything
here, and don't need to read further.

I was writing a little program to get my feet wet using the svga lib.

The problem was that, according to gdb, i was getting a segmentation fault
BEFORE main was reached, which to my naive way of thinking should have
been impossible because i thought main was the entry point into the

Al pointed out that main() is NOT the entry point of a program; crt0
is.  (crt0 is presumably placed in your executable by gcc or one of
the programs gcc execs.)  He also said that the problem might be caused
by not linking in the proper libraries.  Michael suggested that i use
strace to try to figure out what was going on.  Jeroen noted that one
can observe similar behavior (SIGSEGV) in some versions of vgatest
(one of the test programs in the svgalib stuff), but not in others.

All of these observations were very helpful.

First, strace is a useful tool for seeing what system calls your
software makes.

And you can run strace on any program.

Running strace on the two versions of vgatest (one of the programs
Jeroen was talking about) reveals that the vgatest which crashes doesn't
have as many libraries linked in as the one which doesn't crash.

And that was just Al's suggestion: link in another library.

For my program, linking in `-lc' cured the problem.

Thanks again to all who helped.



SIGSEGV before main() is reached (solution and thanks)

Post by Yee On » Tue, 17 Oct 1995 04:00:00

I should have also publicly thanked Keith Lucas

several things about the linking and other things
which occur before main() is reached.  (I'm not
quite ready to summarize what he said for fear of
misinterpreting or misleading.)



SIGSEGV before main() is reached (solution and thanks)

Post by John Swishe » Fri, 20 Oct 1995 04:00:00

<much deletia>

>  For my program, linking in `-lc' cured the problem.

>  Thanks again to all who helped.

>  yeeOn

Yikes!  If you were compiling with gcc (or I'd assume even using the g++ command), I
might try rebuilding my compiler.  The fact that a C compiler does not implicitly link with
the standard c library seems a bit ludicrous to me.  Of course, one of our ever-lovin
HP machines running HP-UX had a similar problem-- the 'c' library was not in the default
path for ld!   Will wonders never cease?

1. SIGSEGV before main() is reached

 > columns on their screen.  You should format to less than 80 characters.]

 > Diamond won't release the specs for their cards unless you pay for them
 > and sign a non-disclosure agreement.  So gnu software doesn't officially
 > support diamond cards.  I suspect that this is your problem.

This, as has been posted, is incorrect.  Diamond has released specs for
their cards.  I think it's rather obvious that this was done, as XFree now
works with the Diamond cards.

Check out for specifications on
working directly with Diamond hardware.
Dave Kraus - Engineer at large

2. fresh openbsdbsd user

3. Understanding threads in Unix

4. SIGSEGV before first instruction of main()

5. unresolve external 'noautodma' in siimage 2.4.21-rc8

6. Swap Space [main mem] ulimit reached

7. xmcd 2.6 on linux, and multiple cdrom drives

8. On solaris2.5 main program is MF cobol then after call dlclose SIGSEGV

9. How I trace back SIGSEGV etc. (was: Re: SIGSEGV trace)

10. "increased VM size+Main-memory" better than "Main-memory+Hard-disk" ??

11. Main function calling another main function

12. I am fine, thanks.