Debugging illegal memory access

[damex]

I'm working on a bsdsocket client. I have a problem though because it crashes the system (guru) when executing connect(). The funny thing is that it crashes only if the server I'm trying to connect to is down. If it's up - connect() succeeds without an issue.

I ran Enforcer and got the following hit:

Alert !! Alert 81000005     TCB: 681B0530     USP: 681B1084
Data: 000005C8 68000010 681B12AC D01B6074 FFFFFFFF 00000001 00000001 81000005
Addr: 68000000 681AFBB8 681AFA38 6800E484 000014B6 681B1278 00001588 --------
Stck: 00F81D38 000000FF 6818103C 00F81D64 00FA71A8 FFFFFFFF 68186D18 6800E484

My suspicion is maybe connect() doesn't have access to SocketBase or some other library? I opened "bsdsocket.library" though and everything works if the server on the other side is up.

Any tips for debugging a situation like this will be appreciated!

[Don_Adan]

Trashing memory, seems to be too small allocated memory area than necessary, or you free memory first and later use this memory area.

[Thomas Richter]

Originally Posted by damex

I'm working on a bsdsocket client. I have a problem though because it crashes the system (guru) when executing connect(). The funny thing is that it crashes only if the server I'm trying to connect to is down. If it's up - connect() succeeds without an issue.

Any tips for debugging a situation like this will be appreciated!

It might then only detect the memory trash when you close the connection again.


In terms of debugging tools, this sounds more like a use case for MuForce + MuGuardianAngel which may also report what was written into the memory, and where it was allocated, but such issues are often resolved by a code review. That is, wait one day, then carefully read the sources again and think about what exactly what each step does.

[patrik]

Calling bsdsocket.library functions can use quite some stack and different amounts depending on what it does.

If you are using the stack to some extent in your code, try increasing the stack size above the standard 4kB and see if it solves the problem, it is a very cheap thing to test.

[damex]

Thank you All for your suggestions!

@patrik Increasing the stack was the first thing I tried. No luck though.

@Thomas Thanks to MuForce + MuGuardianAngel (and probably SegTracker) I managed to find out that the problem is caused by another part of my program. I got some warnings about timer.device (which I also use). When I commented out my timer code the problem disappeared. Now on to debug the timer code