S-Function && MS Visual Studio C/C++: Segmenation Violation -> how to find error?

Hi,

how can I show the location of a Segmentation violation when coding a C S-Function with MS Visual Studio 2010 (and Matlab R2010b). If I run the code in debugging mode and the problem occurs, Visual Studio stops the run with the message "Matlab.exe has triggered a breakpoint", but it is unable to show the source code and thereby the location of the error. It displays the disassembly instead. When I continue the run, Matlab closes down with the "Matlab System Error" Window and the message "Segmentation violation detected".

In a previous bug of my code, Visual Studio was able to show the source code, which made debugging easier.

Anyone has a hint on this?

Cheers,

m

Answer 1

[MIchael]

Hi all,

I don't know if I have found the mistake/solved the problem.

I am solving in an S-Function PDEs that are converted into ODEs. Hence, I have a longer state vector ("Grid Points") and its length should be adjusted through the S-Function parameter ("Number of Points"). I have used 'malloc' and 'free' functions to adjust them. I additionally have written wrapper functions, to be able to use Simulink in Accelerator Mode. So far, the 'malloc' and 'free' functions were implemented for auxiliary variables (not the state vector itself) in both, the output and derivative function, allocating and freeing memory in each time step. Now, I have declared those auxiliary variables global in the wrapper file, so that they only have to be adjusted during start of simulation. I know that global variables shouldn't be the first choice, and I would prefer work-vectors instead. I however, have one multi-dmiensional array that is being adjusted with malloc as well.

Since then, I haven't encountered any problem and also the memory of my PC is not steadily growing any more (have nonetheless always used 'free' functions).

I think/hope, this should resolve my problem.

As a last question, I would like to ask whether multidimensional work vectors in Simulink are possible (maybe I should start a new thread for this question)?

And finally, I would like to thank everybody for all the hints.

Cheers,

MIchael

Answer 2

[Jarrod Rivituso]

I've never heard of anything like this. However, before I knew about debugging S-functions properly, I used to use printf statements everywhere to see how far the code got. I know it isn't ideal, but I made it work in the past.

I think if this problem persists you should contact MathWorks technical support and inform them of the issue.

http://www.mathworks.com/support/

Good luck!

Answer 3

[Kaustubha Govind]

It is likely that the SegV is getting caught in a MathWorks binary (does MSVC show you a stack trace that points to a line number in your S-function?).

Have you tried setting a breakpoint in your S-function and stepping through it line-by-line? This could help you finding the exact line that is causing the SegV.

Answer 4

[Uday M]

If you are using the right C MEX S-Function debugging mechanism, as listed in the following tech-note, http://www.mathworks.com/support/tech-notes/1800/1819.html, you should be able to execute the Simulink model containing the S-Function, which should in turn allow you to step through your S-Function code.

However, if you are unable to diagnose the issue even after following the steps listed in tech-note, it may be useful to contact MathWorks technical support.

Answer 5

[MIchael]

Hi all,

thanks a lot for all your replies.

I follow the instructions as given for "Microsoft Visual C/C++ .NET" (attach to process...). I hope this is alright for MSVC 10 Express.

When MSVC detects the error, it points in the disassembly at the following line:

7C94120E  int         3

I wouldn't be suprised if there is a bug in my coding. At least in normal running mode (no acceleration) Simulink reports an exception in a specific C-File. I allocate in this file memory, but use the free-function afterwards. Maybe this is not optimal but gives a very useful option during simulation runs.

Unfortuntately the error is difficult to find and seems rather to appear randomnly after several simulation runs (memory leak?). Hence, stepping line-by-line would be tedious.

It would be great if anyone of you has a further hint. This error becomes really annoying.

[Kaustubha Govind]

If you are able to post your S-function code, someone might be able to point out errors.

[MIchael]

Hi Kaustubha

the code has more than 1000 lines. I don't know if I should post it..

[Kaustubha Govind]

Ah! Then you might want to go over your code carefully to see if you're not handling memory correctly. Besides allocations and de-allocations, you also must check that you are not reading out-of-bounds memory. Also, if you are work vectors in your S-function, ensure that you are using them correctly.

Finally, if you are able to post the stack trace, that might point to some clues about where the segv is occurring.