From: gtsml o. <gts...@go...> - 2009-10-06 15:41:13
|
Hi, I'm using vnl_conjugate_gradient with VC8 (visual studio 2005) and occasionally I see this error in debug mode: Run-Time Check Failure #2 - Stack around the variable 'z__' was corrupted. This is happening while leaving the function cg_ in the file cg.c This function is literally packed with "goto" btw, could that be the culprit?? Any idea? PS: Callstack: vision.dll!v3p_netlib_cg_(double * x=0x01d6b040, double * e=0x0012f1d4, long * it=0x0012f1c8, double * step=0x01d698b8, double * t=0x0012f1b8, long * limit=0x01d69868, long * n=0x0012f19c, long * m=0x0012f19c, double (double *, void *)* value=0x00f2a9e0, void (double *, double *, void *)* grad=0x00f2aae0, void (double *, double *, double *, void *)* both=0x00f2abf0, void (double *, double *, void *)* pre=0x00f2ad00, double * h__=0x01d6b080, void * userdata=0x01d69858, long * error_code=0x0012f190) Line 1128 + 0xf bytes C > vision.dll!vnl_conjugate_gradient::minimize(vnl_vector<double> & x={...}) Line 171 + 0x50 bytes C++ PPS: FYI, here is a similar question asked in this forum 3 month ago (no answer): Hi, I am currently using Visual Studio 2005 and release 29930 of ffmpeg (which is complied by http://ffmpeg.arrozcru.org/builds/). I get VXL to compile but run into a problem while testing vdl_convert. The test runs to the end and is successful throughout, but ends with this error message: Run-Time Check Failure #2 - Stack around the variable 'buffer2' was corrupted. Is this anything for concern? I tried looking through the archive (btw, is there anyway to search?) but couldn't find anything. Thanks in advance! |
From: Ian S. <ian...@st...> - 2009-10-06 16:18:01
|
gtsml owevwr wrote: > Hi, > > > I'm using vnl_conjugate_gradient with VC8 (visual studio 2005) and > occasionally I see this error in debug mode: > > Run-Time Check Failure #2 - Stack around the variable 'z__' was corrupted. > > This is happening while leaving the function cg_ in the file cg.c > > This function is literally packed with "goto" btw, could that be the culprit?? I know that "Goto Considered Harmful" is well embedded in modern programming "common-sense" but there is no reason for a goto to cause stack corruption per se. > > Any idea? Careless pointer arithmetic would often be cause of such errors. However, I'm not sure if it possible to express dodgy pointer arithmetic in the original Fortran. Can you provide an example that reliably reproduces the error? Ian. |
From: gtsml o. <gts...@go...> - 2009-10-06 16:28:28
|
> Can you provide an example that reliably reproduces the error? I'm afraid I can't, the error function is too complicated. One interesting addition, it is failing when ending in the section with: printf("UNABLE TO SATISFY ARMIJO CONDITION\n"); All the other call, which doesn't end up here, are fine. |
From: Ian S. <ian...@st...> - 2009-10-06 16:42:26
|
gtsml owevwr wrote: >> Can you provide an example that reliably reproduces the error? > > I'm afraid I can't, the error function is too complicated. There is no feasible way for anybody else to debug a run-time error in code like this without a reliable test-case. You could try running your code through valgrind to see if it tells you something more useful. Alternatively, debug through the code, trying to figure out when the memory location described gets corrupted. > > > One interesting addition, it is failing when ending in the section with: > printf("UNABLE TO SATISFY ARMIJO CONDITION\n"); The following assumes that this error is not caused by the corruption described above. Part of the problem is that we didn't write this code, we got it from the netlib repository. You could try searching on netlib.org to see if you can find the author's name, and then seeing if there are any published papers describing the algorithm's implementation. http://en.wikipedia.org/wiki/Wolfe_conditions says something about the ARMIJO condition, which might tell you something about problems with your cost function. > > All the other call, which doesn't end up here, are fine. Which suggests that the two faults are related, without being definitive about which one is the primary cause. Ian. |
From: gtsml o. <gts...@go...> - 2009-10-06 17:16:20
|
Ian, thanks for your help. Here is a quick&cheap workaround: file cg.c, line 120, change this doublereal p, q, r__, s, v=0, w=0, y[50], z__[50], a8, by this: doublereal p, q, r__, s, v=0, w=0, y[100], z__[100], a8, Thanks |
From: gtsml o. <gts...@go...> - 2009-10-06 17:58:13
|
ok, not quite... Still have stack corruption. |
From: gtsml o. <gts...@go...> - 2009-10-07 11:06:54
|
ok, my mistake. In the end it turned out that my cost function was sometime returning NAN when being called with "exotic" parameters. |