pouët.net

Go to bottom

why code keep crashing ? :(

category: code [glöplog]
could people plz tell me if these two binaries crash on their comp?
number 1 :
http://www.mediafire.com/?kwl6wywmewl3c35

numbe 2 :
http://www.mediafire.com/download.php?lu0m7sgcklicdd3

they work fine on my comp though
added on the 2012-07-12 11:56:54 by zorke zorke
1st works, 2nd crashes.

XP SP3
ATI 4850
added on the 2012-07-12 12:03:34 by Intrinsic Intrinsic
both crash after some seconds here.
win7 64bit.
added on the 2012-07-12 12:05:01 by las las
(first one runs longer than the second one)
added on the 2012-07-12 12:05:39 by las las
First one crashes at "ZORKE PRESENTS : CRACKWARE NAME !!"
Second crashes at "WELCOME TO THIS LITT"

Win 7 x64
GTX 560 Ti
added on the 2012-07-12 12:53:00 by cxnull cxnull
Quote:
why code keep crashing?

code not be written good.
heap corruption somewhere? crashes indeed.. but wow! ZORKE..
added on the 2012-07-12 12:56:53 by xTr1m xTr1m
@rasmus: thanks to you, zorke's problem is solved. :p

i second xTr1m. i got a memory access violation. you are trying to read/write to a memory address which is not allocated by your process.

i have two things in my mind.

1) you might be using some extra threads and shared variables/arrays without a lock mechanism.
2) i don't know which framework/library you are using but you might be trying to fill the video buffer using direct access without locking/unlocking. some gfx libs require that.

i believe, these executables run correctly on some machines completely by luck (no timing collisions etc.). there is something wrong with your code.
added on the 2012-07-12 13:07:07 by Skate Skate
Sources will help.
added on the 2012-07-12 13:36:01 by frag frag
it's pretty easy to debug but i can't really tell you what source line to change.

1st:
Code: UPX0:0040121C crashing_func proc near ; CODE XREF: leads_to_crash+E3p UPX0:0040121C UPX0:0040121C var_14= dword ptr -14h UPX0:0040121C var_10= dword ptr -10h UPX0:0040121C var_C= dword ptr -0Ch UPX0:0040121C var_8= dword ptr -8 UPX0:0040121C var_4= dword ptr -4 UPX0:0040121C arg_0= dword ptr 8 UPX0:0040121C arg_4= dword ptr 0Ch UPX0:0040121C arg_8= dword ptr 10h UPX0:0040121C UPX0:0040121C push ebp UPX0:0040121D mov ebp, esp UPX0:0040121F add esp, 0FFFFFFECh UPX0:00401222 pusha UPX0:00401223 mov eax, [ebp+arg_0] UPX0:00401226 mov [ebp+var_10], eax UPX0:00401229 mov eax, [ebp+arg_4] UPX0:0040122C mov [ebp+var_14], eax UPX0:0040122F mov [ebp+var_4], 0 UPX0:00401236 mov eax, [ebp+var_14] UPX0:00401239 imul eax, 7F8h UPX0:0040123F add edi, eax UPX0:00401241 mov eax, [ebp+var_10] UPX0:00401244 shl eax, 2 UPX0:00401247 add edi, eax UPX0:00401249 mov [ebp+var_8], 0Ah UPX0:00401250 mov [ebp+var_C], 2 UPX0:00401257 UPX0:00401257 loc_401257: ; CODE XREF: crashing_func+66j UPX0:00401257 xor ecx, ecx UPX0:00401259 UPX0:00401259 loc_401259: ; CODE XREF: crashing_func+49j UPX0:00401259 mov eax, [ebp+arg_8] ; crash occurs because var_8 is 0xa UPX0:00401259 ; while edi is being incremented by 4 UPX0:00401259 ; probably the cmp, jnz should be replaced with UPX0:00401259 ; cmp, jb UPX0:0040125C mov [edi], eax UPX0:0040125E add edi, 4 UPX0:00401261 inc ecx UPX0:00401262 cmp ecx, [ebp+var_8] UPX0:00401265 jnz short loc_401259 UPX0:00401267 mov eax, [ebp+var_8] UPX0:0040126A mov ecx, 1FEh UPX0:0040126F sub ecx, eax UPX0:00401271 shl ecx, 2 UPX0:00401274 add edi, ecx UPX0:00401276 add esi, [ebp+var_8] UPX0:00401279 inc [ebp+var_4] UPX0:0040127C mov eax, [ebp+var_C] UPX0:0040127F cmp [ebp+var_4], eax UPX0:00401282 jnz short loc_401257 UPX0:00401284 popa UPX0:00401285 leave UPX0:00401286 retn 0Ch UPX0:00401286 crashing_func endp


2nd:
stopped caring
added on the 2012-07-12 18:58:10 by shuffle2 shuffle2
I labelled those wrong, I didn't look at the 1st one, and the code snippet is from the second one.
added on the 2012-07-12 19:00:41 by shuffle2 shuffle2
ok. what i think is happening is that my star-drawing proc is drawing a star outside the screen buffer causing it to crash. but why don't it crash on my computer??
added on the 2012-07-12 23:20:27 by zorke zorke
I'm wondering why many people refuse to use the debugger although it would solve the problem in less than a minute...
added on the 2012-07-12 23:27:11 by hfr hfr
zorke - different OS - different memory access (error) handling.
You might be lucky that your OS does not detect the access violation.
Use a proper debugger and fix that thing!

Providing the code would also fix the problem in a split second due to the massive debugging skills gathered here.

What the others said.
added on the 2012-07-12 23:59:25 by las las
Because it got too drunk at the pub and shouldn't drink & drive?
added on the 2012-07-13 08:25:30 by ringofyre ringofyre
@hfr lol i am using debugger but i can't catch the bug
i'm making some changes in source right now....
@ringofyre: lol. that's fu-nee.
added on the 2012-07-13 09:19:41 by zorke zorke
hey zorke, i'm looking at it now too.
first: you can ignore the description i posted above, i was looking wrong :D

anyways, for nrv-mini i see two problems so far:
http://pastie.org/4248457

the next one is triggered by the function i pasted in my previous post, but i have the explanation wrong, looking at it again now...
added on the 2012-07-13 10:03:08 by shuffle2 shuffle2
here's a few edits of the source:
1 : http://www.mediafire.com/download.php?39q25794fjb3cmz
2 : http://www.mediafire.com/download.php?q63f3jiphiz3irq

which one crashes?

@shuffle2: thanks. i'll take a look at it :)
added on the 2012-07-13 10:10:53 by zorke zorke
here's the other issue:
http://pastie.org/4248535

just remember that y offset is zero based :)
added on the 2012-07-13 10:22:13 by shuffle2 shuffle2
http://www.mediafire.com/download.php?q63f3jiphiz3irq fixes the issue i just posted about.

the other issue http://pastie.org/4248457 is still there, but it's unlikely to often cause a crash since it is only reading/writing 4 bytes off the end of the ppvBits array.
added on the 2012-07-13 10:32:32 by shuffle2 shuffle2
zorke:
Don't know if you still need some help, but I will still insert my coins here :).

Usually when a program does not crash on your computer and especially if the debugging version works fine, the problem is with some uninitialized variable causing all other problems (like the memory writes to non allowed locations described here).
added on the 2012-07-13 11:14:15 by deepr deepr
@shuffle2 : thanks. just making sure, is the main crashing problem fixed? (before i fix link to prod)
@deepr : thanks. i didn't know that just now :) and insert no coins (rzr) was the prod i borrowed the "DOS bar" layout from
added on the 2012-07-13 11:25:59 by zorke zorke
ok. in the end, it was the random number generator's fault. i changed the range, and voila! it no more crasHHes :) thanks everyone!

and could you plz confirm that it doesn't crash anymore? it's very annoying since it runs fine on my comp >:(
added on the 2012-07-13 11:58:45 by zorke zorke
ok. in the end, it was the random number generator's fault. i changed the range, and voila! it no more crasHHes :) thanks everyone!

and could you plz confirm that it doesn't crash anymore? it's very annoying since it runs fine on my comp >:(
added on the 2012-07-13 12:04:40 by zorke zorke
I can't see how random number generator will cause access violation depending on it's range. It's probably has something to do with what you do with the output.
Keep in mind that there is no voodoo in programming...
added on the 2012-07-13 12:50:43 by TLM TLM

login

Go to top