Register | Login
Views: 19364387
Main | Memberlist | Active users | ACS | Commons | Calendar | Online users
Ranks | FAQ | Color Chart | Photo album | IRC Chat
11-02-05 12:59 PM
0 user currently in Programming. | 3 guests
Acmlm's Board - I2 Archive - Programming - another memory management issue qq | |
Pages: 1 2Add to favorites | "RSS" Feed | Next newer thread | Next older thread
User Post
beneficii

Lakitu
Level: 36

Posts: 409/567
EXP: 299656
For next: 8454

Since: 06-27-04
From: Cordova, TN, USA

Since last post: 14 hours
Last activity: 6 hours
Posted on 08-17-05 11:10 AM Link | Quote
I rewrote my program from the start with an eye to memory management. I make sure to NULLify my pointers when they are initialized and free them when I'm done with them. Still, I have an interesting problem. I have a function that sets up the current mode the program is in (i.e. what it's editing: sprites/pointers/whatnot) and then draws the image to the screen. Well it draws the image to the screen fine and is the last function in that particular switch case. Then the program crashes about a second later. When I added a MessageBox function to right before the calling of that function in the case, however, the message box came up, the thing drew to the screen, and to my amazement it didn't crash!

In other words, the message box appearing seem to have prevented the program from crashing! Does anybody have any idea what that's about?

pls can anyone help me qq this program keeps hurting my feelings pls help me thk u ga


(edited by beneficii on 08-17-05 02:16 AM)
Lenophis

Super Koopa
Level: 44

Posts: 656/830
EXP: 584360
For next: 26925

Since: 03-15-04
From: Duluth, MN

Since last post: 4 hours
Last activity: 3 hours
Posted on 08-17-05 11:25 AM Link | Quote
Well, I'm not really sure, but it could be an hWnd problem. That, or a pointer is giving a problem.

Could you paste the switch code?
beneficii

Lakitu
Level: 36

Posts: 410/567
EXP: 299656
For next: 8454

Since: 06-27-04
From: Cordova, TN, USA

Since last post: 14 hours
Last activity: 6 hours
Posted on 08-17-05 06:50 PM Link | Quote
Originally posted by Lenophis
Well, I'm not really sure, but it could be an hWnd problem. That, or a pointer is giving a problem.

Could you paste the switch code?


I'd prefer not. It's under a case in the switch(LOWORD(wparam)) under the case WM_COMMAND. Essentially, if I put up a message box anywhere around the modeswitch function (or in it), then the program won't crash. But if I don't put up the message box, then the program will crash. Also, if I call modeswitch after that to load another world, it seems that'll make the program crash too.
Dish

Spiny
Level: 38

Posts: 530/596
EXP: 355646
For next: 14801

Since: 03-15-04
From: Disch

Since last post: 18 days
Last activity: 18 days
Posted on 08-17-05 08:26 PM Link | Quote
Crashes like this usually aren't that hard to track down -- just find the line that the program is crashing on (this can be done in MSVS very easily by hitting the "break" option when the program crashes). When you know where the thing is going wrong -- examine everything that could make it go wrong -- whether it be a bad pointer, an out-of-bounds write, or whatever.

So yeah -- you gotta isolate the crash in order to solve it. If the crash is predictable, consistent, and easily reproduced (you made it sound like it's all three), then you should have no trouble finding out where the problem is. Like I said just break execution at the crash -- if it puts you at some garbage code (like some disassembly or a standard lib file), move back on the call stack until you reach your code.


(edited by Disch on 08-17-05 11:28 AM)
beneficii

Lakitu
Level: 36

Posts: 412/567
EXP: 299656
For next: 8454

Since: 06-27-04
From: Cordova, TN, USA

Since last post: 14 hours
Last activity: 6 hours
Posted on 08-17-05 08:29 PM Link | Quote
Originally posted by Disch
Crashes like this usually aren't that hard to track down -- just find the line that the program is crashing on (this can be done in MSVS very easily by hitting the "break" option when the program crashes). When you know where the thing is going wrong -- examine everything that could make it go wrong -- whether it be a bad pointer, an out-of-bounds write, or whatever.

So yeah -- you gotta isolate the crash in order to solve it. If the crash is predictable, consistent, and easily reproduced (you made it sound like it's all three), then you should have no trouble finding out where the problem is. Like I said just break execution at the stack -- if it puts you at some garbage code (like some disassembly or a standard lib file), move back on the call stack until you reach your code.


Well, my normal mode was just by putting message boxes and testing where the crash occurs. For some reason, the message box was stopping it crashing and that's what has me confused, but I'll see if Bloodshed has that break option.
Dish

Spiny
Level: 38

Posts: 531/596
EXP: 355646
For next: 14801

Since: 03-15-04
From: Disch

Since last post: 18 days
Last activity: 18 days
Posted on 08-17-05 08:32 PM Link | Quote
ahh yeah... I used to do that too before I got semi-familiar with VS's debugger.

Breakpoints, variables watches, and memory viewers beat Message boxes anyday ;D


Anyway, another alternative would be to output to a text file or something instead of doing a message box. I'd still recommend a debugger over that though.
HyperLamer
<||bass> and this was the soloution i thought of that was guarinteed to piss off the greatest amount of people

Sesshomaru
Tamaranian

Level: 118

Posts: 6371/8210
EXP: 18171887
For next: 211027

Since: 03-15-04
From: Canada, w00t!
LOL FAD

Since last post: 2 hours
Last activity: 2 hours
Posted on 08-19-05 10:56 AM Link | Quote
Keh. Debugging = printf(), scanf() and assert(). Seriously, it's pretty simple to make a simple debug console on the command line - put some button or something in that prompts for a simple command - and REALLY useful.
sloat

Level: 16

Posts: 74/85
EXP: 18044
For next: 2212

Since: 05-21-04
From: South Central Delaware

Since last post: 19 days
Last activity: 5 hours
Posted on 08-20-05 02:02 AM Link | Quote
Debuggers...breakpoints...watches...MessageBox...assert...logging...all pale in comparison to the awesome power of Beep!
HyperLamer
<||bass> and this was the soloution i thought of that was guarinteed to piss off the greatest amount of people

Sesshomaru
Tamaranian

Level: 118

Posts: 6396/8210
EXP: 18171887
For next: 211027

Since: 03-15-04
From: Canada, w00t!
LOL FAD

Since last post: 2 hours
Last activity: 2 hours
Posted on 08-20-05 02:46 AM Link | Quote
Ah yes... How could I forget Beep()? That's how they debugged computers before command lines even existed. Hell, even now, your BIOS will use it if something goes horribly wrong. Plus, random beeps are fun.
beneficii

Lakitu
Level: 36

Posts: 420/567
EXP: 299656
For next: 8454

Since: 06-27-04
From: Cordova, TN, USA

Since last post: 14 hours
Last activity: 6 hours
Posted on 08-22-05 02:58 AM Link | Quote
Originally posted by Disch
ahh yeah... I used to do that too before I got semi-familiar with VS's debugger.

Breakpoints, variables watches, and memory viewers beat Message boxes anyday ;D


Anyway, another alternative would be to output to a text file or something instead of doing a message box. I'd still recommend a debugger over that though.


OK, I looked at Bloodshed's debugger and read the help file for it. Nevertheless, I have some questions: How do I get my program to stop at a breakpoint? I set a breakpoint and then do the debug compile and run it, but it doesn't stop at that breakpoint. I know I'm missing something, but I can't find it in the help file (which gives no good example).

Thanks.
sloat

Level: 16

Posts: 75/85
EXP: 18044
For next: 2212

Since: 05-21-04
From: South Central Delaware

Since last post: 19 days
Last activity: 5 hours
Posted on 08-22-05 09:49 AM Link | Quote
With Visual Studio, I'm pretty sure you have to run the app through the IDE. I'm not 100% sure though and I'm not sure if that applies to Bloodshed. It could also be that your breakpoint is just never reached.
beneficii

Lakitu
Level: 36

Posts: 423/567
EXP: 299656
For next: 8454

Since: 06-27-04
From: Cordova, TN, USA

Since last post: 14 hours
Last activity: 6 hours
Posted on 08-22-05 07:20 PM Link | Quote
Originally posted by sloat
With Visual Studio, I'm pretty sure you have to run the app through the IDE. I'm not 100% sure though and I'm not sure if that applies to Bloodshed. It could also be that your breakpoint is just never reached.


I was thinking that the breakpoint was not being reached also, so I put it in the first line of the WM_CREATE of my main window (which did load), but the program still did not break execution.

I'm not entirely sure how Bloodshed does it. I read through the help file. (I think the Help file has bad formatting, too). Here is text from it:

Launching your program into the debugger is easy. Just go to the Debug menu and click on Debug (shortcut : F8).
If you do not have debugging information set in your project, Dev-C++ will ask you if you want to rebuild your program with these information enabled. You can manually select that option in Compiler Option in the Linker section. After your project has been rebuild, you can launch Debug again.


The debugger has now loaded your program and runs it. but until that you can learn to control several aspects of the debugger :

- Setting Breakpoints in your codeID_BREAKPOINT

- Stepping in your codeID_STEPDEBUG

- Displaying variables value and classes/structures membersID_DISPLAYDEBUG

- BacktracingID_BACKTRACE

- Using the CPU WindowID_CPUWINDOW

The output Dev-C++ receives from GDB is displayed in the Debug Output sheet at the bottom of Dev-C++.

This output is probably only interesting if you are familiar with GDB. You can also send commands directly to it (if you do not know GDB, you can type the help command for to have a list) by using the edit box just above the output (see screenshot below).


I'm not entirely sure what debugger information is, but I did set a breakpoint in the code and click Debug. It asked me if I wanted to compile with information and I said yes. It compiled, I then simply ran it. The breakpoint was set on the first line of the code in the body of case WM_CREATE in the WndProc's switch(msg) statement. The windows loads fine, but the program does not break. Perhaps there is somebody familiar with Bloodshed here?


(edited by beneficii on 08-22-05 12:49 PM)
Kyoufu Kawa
I'm not bad. I'm just drawn that way.
Level: 70

Posts: 2025/2481
EXP: 3008456
For next: 7355

Since: 03-19-04
From: Catgirl Central

Since last post: 14 hours
Last activity: 13 hours
Posted on 08-22-05 07:33 PM Link | Quote
I myself required some nice debugging myself. YDimGame kept resetting to zero! So I peppered my code with printf("DEBUG: YDimGame is now %d\n", ydimgame); lines.

Eventually, I found that my game's config routines were loading the player's pant color into ydimgame


So yeah, PrintF for the win.

In VB, I just click auto-comment and remove apostrophes until it breaks, basically.
beneficii

Lakitu
Level: 36

Posts: 424/567
EXP: 299656
For next: 8454

Since: 06-27-04
From: Cordova, TN, USA

Since last post: 14 hours
Last activity: 6 hours
Posted on 08-22-05 09:50 PM Link | Quote
Originally posted by Kawa-oneechan
I myself required some nice debugging myself. YDimGame kept resetting to zero! So I peppered my code with printf("DEBUG: YDimGame is now %d\n", ydimgame); lines.

Eventually, I found that my game's config routines were loading the player's pant color into ydimgame


So yeah, PrintF for the win.

In VB, I just click auto-comment and remove apostrophes until it breaks, basically.


Hmm, commenting it out until it breaks actually seems to be a good idea. Thanks Kawa!
HyperLamer
<||bass> and this was the soloution i thought of that was guarinteed to piss off the greatest amount of people

Sesshomaru
Tamaranian

Level: 118

Posts: 6490/8210
EXP: 18171887
For next: 211027

Since: 03-15-04
From: Canada, w00t!
LOL FAD

Since last post: 2 hours
Last activity: 2 hours
Posted on 08-22-05 10:42 PM Link | Quote
VB has awesome debugging, though. You don't need to do that. Use breakpoints and debug.print; you can even type code in the Immediate window and press Enter to execute it. (Of course, in C's defense, this is only possible because VB is interpreted, but yeah. )

Also, Kawa, that's exactly what assert() is for. Instead of having to constantly watch for a specific output, you could just put 'assert(YDimGame != 0)' in a commonly-executed loop or something. IIRC the program will stop, or at least warn you, once that condition becomes false, and then you just look at the rest of the debug output to see what happened. (Tip for VB users: debug.assert. )
Kyoufu Kawa
I'm not bad. I'm just drawn that way.
Level: 70

Posts: 2032/2481
EXP: 3008456
For next: 7355

Since: 03-19-04
From: Catgirl Central

Since last post: 14 hours
Last activity: 13 hours
Posted on 08-22-05 10:47 PM Link | Quote
Umm... no.
It happened out of any loop. In the initialization code.
beneficii

Lakitu
Level: 36

Posts: 426/567
EXP: 299656
For next: 8454

Since: 06-27-04
From: Cordova, TN, USA

Since last post: 14 hours
Last activity: 6 hours
Posted on 08-23-05 12:58 AM Link | Quote
For me, I think that using break or goto to test your program would be easier then commenting out a bunch of your code. I actually did the goto statement (I know I know the goto statement is evil; I only am using it for testing) in a function and the problem that turned out was a flag that got set that caused another function later on to get messed up (I have a couple ideas to what it is). I thought the problem was a lot more complicated, but I'm starting to get a little confident again.

When I get home from work tonight, I'm going to set to it.
HyperLamer
<||bass> and this was the soloution i thought of that was guarinteed to piss off the greatest amount of people

Sesshomaru
Tamaranian

Level: 118

Posts: 6510/8210
EXP: 18171887
For next: 211027

Since: 03-15-04
From: Canada, w00t!
LOL FAD

Since last post: 2 hours
Last activity: 2 hours
Posted on 08-23-05 11:36 AM Link | Quote
Originally posted by Kawa-oneechan
Umm... no.
It happened out of any loop. In the initialization code.

It needn't be in a loop, necessarily. That's just where you start. Basically anywhere you'd put a printf, put an assert instead, so you don't get a lot of useless output telling you everything is still alright.
Kyoufu Kawa
I'm not bad. I'm just drawn that way.
Level: 70

Posts: 2043/2481
EXP: 3008456
For next: 7355

Since: 03-19-04
From: Catgirl Central

Since last post: 14 hours
Last activity: 13 hours
Posted on 08-23-05 03:02 PM Link | Quote
But... but.... I like wading through the game's log!
beneficii

Lakitu
Level: 36

Posts: 428/567
EXP: 299656
For next: 8454

Since: 06-27-04
From: Cordova, TN, USA

Since last post: 14 hours
Last activity: 6 hours
Posted on 08-24-05 12:57 PM Link | Quote
OMG OMG OMG I just found out what was wrong with my program!

The problem was in a careless variable initialization in a class method that caused it to sometimes try to read from a NULL pointer as though it were an arrary. It's so embarrassing.

I am getting tired for playing these search around games, but thankfully they're getting less and less.
Pages: 1 2Add to favorites | "RSS" Feed | Next newer thread | Next older thread
Acmlm's Board - I2 Archive - Programming - another memory management issue qq | |


ABII


AcmlmBoard vl.ol (11-01-05)
© 2000-2005 Acmlm, Emuz, et al



Page rendered in 0.012 seconds.