Member Avatar for epicasian

First off, sorry if this is the wrong section, but sense I'm working with graphics, I thought it would be more appropriate for the game dev topic.

Okay, whenever I start debugging from VC++, I segfault. But when I run my program outside of VC++, it runs perfectly fine.

If I need to add more details, please tell me, I'm just confused haha.

Thanks,
~EpicAsian

  • 4 Contributors
  • 6 Replies
  • 494 Views
  • 4 Days Discussion Span
  • Latest Post Latest Post by Rajesh R Subram

Dani AI

Generated

This pattern usually points to either an environment difference (wrong working directory or missing asset) or memory corruption whose symptoms change when the debugger alters memory layout. The crashes described by — once in an image-loading constructor, once while flipping an SDL buffer — match both cases: a failed load returning a null pointer, or a heap/stack overwrite that only manifests under the debugger. ’s working-directory suggestion and /’s memory-corruption/debugging tips are both relevant; the following expands those checks into concrete steps.

Confirm the process working directory and the actual file paths used at load time. In Visual Studio set Project → Properties → Configuration Properties → Debugging → Working Directory to a known folder (for example $(ProjectDir) or $(TargetDir)). Alternatively add image files to the project and set their Solution Explorer property “Copy to Output Directory” to “Copy if newer” so the EXE and assets live together. Log or print the full filename before opening and explicitly test for file existence; treat a failed load as an error rather than assuming a non-null return.

Treat the crash as memory-corruption until proved otherwise. Enable break-on-first-chance for access violations (Debug → Exceptions or Exception Settings) so the debugger stops at the exact faulting instruction. Build the Debug configuration with runtime checks (/RTC) and the debug CRT (Runtime Library → Multi-threaded Debug DLL /MDd) and enable the CRT debug heap or leak checks (_CrtSetDbgFlag) to catch overruns. Use the Watch and Memory windows to inspect suspicious pointers and buffer contents.

If the problem remains elusive, check ABI/library mismatches (debug vs release SDL libs, x86 vs x64), try attaching the debugger to the already-running EXE to compare behavior, and run heap-checking tools (Application Verifier, Dr. Memory, AddressSanitizer where available) or a static analyzer. If none of these narrow it down, a minimal reproducible example — as suggested — will make the underlying bug apparent.

Recommended Answers

All 6 Replies

Member Avatar for daviddoria

Can you produce the smallest piece of code that does this and post it here?

Dave

Member Avatar for epicasian

Well, I would like to, but it happens in random places. In a class of my engine, in the constructor it takes a filename argument and loads and optimizes that image.It segfaulted there once. Another time, it segfaulted when I flipped the buffer to the screen in SDL.

My guess is that VC++ is looking for the image file I specified in a temporary directory and it's not there.

Thanks for the reply,
~EpicAsian

Member Avatar for daviddoria

You should be able to set the "working directory" in VC. That is where it will look for images without a path specified. Another thing you could check is that VC has the same library path order that your system has. Maybe it is linking to different versions of the libraries that you are using?

Member Avatar for epicasian

I don't think it's linking to a different version of the SDL library, because I download VC++ and SDL at the same time. I recently converted from Dev-C++ to VC++, so I'm somewhat new to the VS environment. I don't see why VC++ would be throwing errors if the images are in the same directory as the *.exe.

Thanks,
~EpicAsian

Member Avatar for wildgoose

Look for data not set! You should probably have a difference between a debug and release build as well. Data will be initialized differently. Also running within an I.D.E. will move code around in memory!

Also look for a memory overwrite. Writing past the end of allocated memory. Check for unhandled errors.

Single-step your code!

Edited by wildgoose because: n/a
commented: good answer +28
Member Avatar for Rajesh R Subram

If your code doesn't work within the IDE, there's no question of shipping it ever.

The debugger does you a huge favour by watching what you're doing with the memory and tells you when your code does something insane (like stomping on memory that it doesn't own).

Single stepping should help you find the problem.

commented: good answer +28
Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.