Sign in to follow this  

stack smashing detected

This topic is 3926 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi, I wrote an opengl program on windows, and it works perfectly. However when I test it on linux (ubuntu) it works for a small input file, but not a large one. For example this works:
 $ ./a.out cube.stl 
When I use a larger input file I get a stack smashing error.
$ ./a.out Pump.stl
*** stack smashing detected ***: ./a.out terminated
Aborted (core dumped)
Does anyone know what this means? Thank you

Share this post


Link to post
Share on other sites
My guess is that message means that the program has used up all of the available stack and therefore can no longer continue executing.

I would guess that the code for the program uses a local variable to hold the contents of the file. Local variables reside on the stack. So there's no problem reading in a small file but there is reading in a larger file. If that is the case, the solution is to allocate memory from the heap (ie using malloc or new) to hold the contents of the file.

Share this post


Link to post
Share on other sites
Quote:
Original post by LessBread
My guess is that message means that the program has used up all of the available stack and therefore can no longer continue executing.

I would guess that the code for the program uses a local variable to hold the contents of the file. Local variables reside on the stack. So there's no problem reading in a small file but there is reading in a larger file. If that is the case, the solution is to allocate memory from the heap (ie using malloc or new) to hold the contents of the file.


But isn't that a stack overflow, not a stack smash?

A stack smash normally occurs when you overflow a buffer and overwrite the function calls return address, so when the stack tries to pop it goes into la-la land.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by PlayfulPuppy

But isn't that a stack overflow, not a stack smash?

A stack smash normally occurs when you overflow a buffer and overwrite the function calls return address, so when the stack tries to pop it goes into la-la land.


Thanks

Share this post


Link to post
Share on other sites
Quote:
Original post by PlayfulPuppy
Quote:
Original post by LessBread
My guess is that message means that the program has used up all of the available stack and therefore can no longer continue executing.

I would guess that the code for the program uses a local variable to hold the contents of the file. Local variables reside on the stack. So there's no problem reading in a small file but there is reading in a larger file. If that is the case, the solution is to allocate memory from the heap (ie using malloc or new) to hold the contents of the file.


But isn't that a stack overflow, not a stack smash?

A stack smash normally occurs when you overflow a buffer and overwrite the function calls return address, so when the stack tries to pop it goes into la-la land.


Ok.

Share this post


Link to post
Share on other sites
Quote:
Original post by PlayfulPuppy
Quote:
Original post by LessBread
My guess is that message means that the program has used up all of the available stack and therefore can no longer continue executing.

I would guess that the code for the program uses a local variable to hold the contents of the file. Local variables reside on the stack. So there's no problem reading in a small file but there is reading in a larger file. If that is the case, the solution is to allocate memory from the heap (ie using malloc or new) to hold the contents of the file.


But isn't that a stack overflow, not a stack smash?

A stack smash normally occurs when you overflow a buffer and overwrite the function calls return address, so when the stack tries to pop it goes into la-la land.


"Smashing the stack" colloquially refers to exploiting a buffer overflow (where do you think that buffer is? On the heap? No, it's on the stack, so the overflow is a stack overflow) deliberately in order to change the return address.

The OS can't distinguish malicious intent from an accident, however, so it assumes that anything that tries to overwrite the return address is an attempted stack smash.

Share this post


Link to post
Share on other sites
Have you started up gdb to take a look at the spot where the problem his happening? With the amount of information available I can only speculate, but it would seem that either the difference in libraries, compilers, or compiler options (or clearly a combination of these) from windows to *nix is creating the problem (the stack overflow).

Starting up gdb and walking through should at least show you where this is happening and give you some clues as to why. That may help someone here diagnose the problem or at least what to research..


hth.. #dth-0

Share this post


Link to post
Share on other sites
Quote:
Original post by xiuhcoatl

Starting up gdb and walking through should at least show you where this is happening and give you some clues as to why. That may help someone here diagnose the problem or at least what to research..


I tried that already and suprisingly wasn't helpful. But thanks for the suggestion.

Share this post


Link to post
Share on other sites

This topic is 3926 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this