Access Violation

[maxg...@gmail.com]

Hi, I'm getting a strange crash of my program using the Dislin library (Windows 10 64 bit, MINGW 64 , GCC 10.2, Latest Dislin version). I'm using dislin to plot several (more than 30) curves in 2D, I'm using a VIRTual file then  converted to a png. The png is then shown in a wxFrame ( wxWidgets)

It was very difficult to have some information about the crash., But in the end, using a post-mortem debugger called DrMingw, I got

EXCEPTION PID=3808 TID=15904 ExceptionCode=0xc0000005 dwFirstChance=1
EXCEPTION PID=3808 TID=15904 ExceptionCode=0xc0000005 dwFirstChance=0
AteSfp28BiDi.exe caused an Access Violation at location 00000000005EEAA8 in module AteSfp28BiDi.exe Writing to location 00000000071E5E78.

AddrPC           Params
00000000005EEAA8 00000000000000FF 0000000006CAC020 00000000000000FF  AteSfp28BiDi.exe!qqvlin32h
0000000000000001 0000000006CAC020 00000000000000FF 00000000000000FF
00000000000000FF 00000000000000FF 00000000000000FF 0000000000000000
0000000006CAC020 00000000000000FF 0000000000000000 0000000000000000
00000000000000FF 0000000000000000 0000000000000000 0000000000000001
00000000000000FF 0000000000000000 0000000000000001 0000000003C6D8D0

EXIT_THREAD PID=3808 TID=4304 dwExitCode=0xc0000005
EXIT_THREAD PID=3808 TID=16864 dwExitCode=0xc0000005
EXIT_THREAD PID=3808 TID=10740 dwExitCode=0xc0000005

I inspected my code but I'm still unable to understand the reason of the crash. It seems related to qqvlin32h, a Dislin function.

What is the main purpose of the qqvlin32h function?

Is there any possible reason for the crash (access violation) in qqvlin32? Any possible access violation in it?

One possible way to understand the issue is to have access to the source code, or better have the libraries compiled with GDB debugging information.  I know that subscribing the Dislin support I can have access to the source code but is there any possible way to get (or compile, using the MinGW environment) the libraries with the debugging information?

Any help appreciated.

Regards

Max 

[Helmut Michels]

Hi Max,

the routine qqvlin32h plots just a horizontal line with 32-bit pixels to the virtual buffer. It's unlikely that it has caused

the crash directly. I think that a problem before has caused the crash in qqvlin32h. Either in Dislin, or in the program.

Are you creating all curves in one plot, or are you creating a series of plots? Are there any Dislin warnings, especially

about memory allocation? Are you using a lot of automatic arrays that could cause stack problems? Is it possible

to reduce the program to an example code, that can reproduce the crash? This would be the easiest way to find the

reason.

With best regards,

Helmut

[maxg...@gmail.com]

Dear Helmut,

First of all I0'd like to thank your your attention. You wrote

> Are you creating all curves in one plot, or are you creating a series of plots?

I'm plotting in the VIRT buffer several curves calling curve() in a loop. Then I plot a non linear grid, plotting horizontal lines again using curve(). I'm not calling any function to plot an horizontal  line explicitly. The horizontal line are plotted to create a non linear grid, I'm plotting experimental data using a non linear transformation ( - log10( -log10 (y)  with y positive in (0,1) so no zero or 1 is possible). To create a proper grid I'm using a code like the following pseudo code to plot a single  horizontal line

double x[2]

double y[2]

x[0] = x0;

x[1]= x1;

y[0] = yValue;

y[1] = yValue;

curve (x , y , 2);

Do you see any possible problem?

> Are there any Dislin warnings, especially about memory allocation?

At the moment the program is a Windows application, I'll be trying to attach a console (using AttachConsole() ) to get any message from standard error and output.

> Are you using a lot of automatic arrays that could cause stack problems?

I'm using two

std::vector < std::vector<double> > x;

std::vector < std::vector<double> > y;

to hold the data points. Usually up to 40 curves with 10 datapoints each. So I don't think there is a stack problem. The vector are used in code like

for (uint64 index =0; index < x.size(); ++size)

{

 curve ( x[index].data() ,  y[index].data() ,  x[index].size() );

}

I already checked that x and y have the same size and each x[index] and  y[index] vectors have the same size.

> Is it possible to reduce the program to an example code, that can reproduce the crash?

It is very difficult. It's a multi thread program, a working thread is acquiring the data then it sends and event message to the main thread to just re-plot the curves. Using wxWidows the main thread can be used for the GUI only.

During the plotting phase no data are acquired. Moreover the crash appears in about 10% of the acquisition runs....it is not reproducible. I'm still looking for issue in my code........

Regards

Max

[Helmut Michels]

Dear Max,

I can't see any problems with the stack or with the curve statements.  Do you think that the crash appears

during the grid plot, or during the plot of the data? It should be easy to check. I have made a stress test of

plotting a few thousand of curves with random data to the virtual buffer, but no crash appeared, even not for

horizontal lines. Curve switches automatically to horizontal lines for plotting horizontal segments. It is faster.

By the way, you can just write the Dislin warnings to a file with the option errdev ("file") before disini. You

don't have to create a console application.

With best regards,

Helmut 

[maxg...@gmail.com]

Dear Helmut, you wrote

> Do you think that the crash appears during the grid plot, or during the plot of the data?

My guess is that the crash appears during the grid plot. The plot data have no horizontal segment (or at least is very very unlikely, I would  say impossible). The data points are the bit error ration of a receiver versus the input power. The only possible way yo get an horizontal segment (i.e. two points in the curve with the same ordinate) is to be in a "error floor" conditions that is not present. Moreover the class plotting the "non linear grid" is the only one experiencing the issue.

I added the suggested errdev() function, just to get the warnings. I hope to create a minimal example in which I just plot the grid trying to get the crash.

On more question. Is it possible that the crash appears when the horizontal line is outside the "page area" or "axis frame area"? I was using nocheck() after disini() and now I added a call to clpbor("AXIS"). Hopefully the clipping helps.....

Regards (and thank for your attention)

Max

[Helmut Michels]

Normally, everthing outside of the page is clipped, so that you cannot plot anything outside of it.The routine curve moves

the clipping borders temporarily from the page borders to the axis system borders. If you do it directly with clpbor ("axis"),

the call in curve is ignored. There should be no difference, except that you should reset the clipping borders back to the page

after curve. I still cannot reproduce a crash, even not if the data points are outside of the page or axis system. There must be

something special in your program. I hope that you can create a small example that shows the crash.

With best regards,

Helmut

[maxg...@gmail.com]

Dear Helmut,

you wrote

> I hope that you can create a small example that shows the crash.

Yes, I think I got it!!!  After a debugging session I found which function is creating the qqvlin32h() call that is causing the crash. It is legend()!!!! When the legend() function is called the debugger signals the crash in qqvlin32h().

I created,  a small c++ console program showing the issue. I'm attaching it and hopefully you can confirm where the bug (or feature? ) is. Maybe be is just my fault and not a Dislin issue, but nobody can check this..... better than you.

The program has two parameters controlling the behavior.

NUM_OF_LINES
MARKER_MODE

It seems that if MARKER_MODE is equal to zero the program always works successfully, regardless the value of NUM_OF_LINES. If MARKER_MODE is equal to one there is a minimum value of NUM_OF_LINES that is causing the crash.

In my real code (measuring the bit error ratio) if NUM_OF_LINES is greater than 31 the program crashes. In the example attached and in my used platform the minimum value is 35.

If  MARKER_MODE is equal to one and NUM_OF_LINES is greater than 35 (or 31) the program systematically crashing. IN the example I set it to 70.

I do hope to get some advice from you.

Some addtional information

I'm linking the double precision static library, using Windows 10 Pro and Windoews 7 Pro SP1. The compiler is gcc 10.2.0 from MinGW64 (MSYS2).

Regards

Max

[Helmut Michels]

Dear Max,

thank you for the example code. Yes, that's it. I could reproduce the crash. It is caused by a symbol in a legend line that

is outside of the page. I will fix it and send you a updated Dislin library for Mingw. The bug fix will be included in the next

upgrade.

With best regards,

Helmut

[Helmut Michels]

Hi,

the access violation is now fixed in the new Dislin version 11.4, which is available from https://www.dislin.de

With best regards,

Helmut