ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
That is something that I've run into as well. Do you have some kind of optimisations turned on for the release build (Project->Settings->C/C++ tab)? If so, it's possible that a dodgy piece of code is being optimised away somehow. Can you step through the code and identify where the crash occurs?
FWIW I think the "memory access violation" message is equivalent to "segmentation fault" in Linux coding, i.e. your program has tried to access memory outside of it's address space. This is very commonly caused by NULL pointers.
Well, I don't know any real details about how optimisation works. Basically, the compiler will alter the code in some way to make it either faster or smaller (depending on which optimisation is selected). I'd guess that what happened in this case was that the optimisations in some way changed the problem area of the code, so that it wasn't a problem. The error certainly wasn't being ignored, it was just never happening at all.
I've run into the reverse problem at times. Code runs fine in debug mode, but crashes in release mode. I believe another thing that debug mode does, is to allocate extra space when creating arrays and such. So... when working in debug mode, often times accessing an array beyond its bounds will succeed, but then it will fail in release mode because that extra debug memory goes away. Anyway, not really the problem you are seeing, but it is something else to watch for...
Originally posted by Hady Hi & Thanks a lot for your reply.
by why when I have optimization "Maximum Speed" for Release mode,
it ignores NULL pointers?
uninitialized variables contiain random (unpredictable, at least) data. whatever random data was in the pointer during the debug build caused an access violation, but the random data in the release build didn't, but it could have - wherever it was pointing wasn't a place that the OS was worried about.
According to C++ standard, dereferencing bad pointers (NULL, uninitialized, or out of scope) is "undefined". That means that your implementation can throw an exception, do what "you meant to do", do something else, or do nothing at all. I've had the same problem with BCB6. Windows sometimes lets your program dereference a bad pointer and not throw an exception (especially when accessing int data members), but Linux is very good about letting you know when you've messed up.