<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Hello,</div><div><br></div><div>Thank you very much.</div><div>I tried to do that, and I think I found where overwriting occurs.</div><div><br></div><div>By compiling this code (modified for debugging)&nbsp;<a href="http://pastebin.ca/2430971">http://pastebin.ca/2430971</a></div><div>with</div><div><div>$ g++ -g -Wall -c -O0 -I${HOME}/adolc_base/include adolc_test.cc</div><div>$ g++ adolc_test.o ${HOME}/adolc_base/lib64/libadolc.a&nbsp;</div></div><div>and</div><div>$ gdb a.out</div><div>and to copy &amp; paste commands&nbsp;<a href="http://pastebin.ca/2430973">http://pastebin.ca/2430973</a>&nbsp;, gdb&nbsp;should go the place of the problem,</div><div>&nbsp;"adub operator * ( const badouble&amp; x, const badouble&amp; y )" at line 1001 in adouble.cc.</div><div>&nbsp;(I tested in my three environment that this gdb commands works)</div><div>The tail of gdb output is like this:&nbsp;<a href="http://pastebin.ca/2430974">http://pastebin.ca/2430975</a>&nbsp;(this is in Debian).</div><div>From this place, doing "n" gdb command several times changes what I declared as const.</div><div><br></div><div>This seems to me that,&nbsp;variable "a" and "b" in my code is stored at index 5 and 4 respectively, in global array&nbsp;&nbsp;"globalTapeVars.store"&nbsp;&nbsp;inside ADOL-C.</div><div>By several "n" command&nbsp; above, changes "globalTapeVars.store[4]", namely "b".</div><div>The problem seems to be in "next_loc()" function.</div><div>As argument &nbsp;x and y (for "adub operator *")&nbsp;are declared as const, it seems next_loc() should</div><div>return a place that is different from both x's and y's, but in this case it returns the place same as x, and</div><div>consequently x is overwritten.</div><div><br></div><div>(The tail of gdb output at this point is <a href="http://pastebin.ca/2430984">http://pastebin.ca/2430984</a> (Debian).</div><div>please compare&nbsp;globalTapeVars.store[4] at the top and at the bottom,</div><div>and locations of variables x, y, locat at line 5,7,135.)</div><div><br></div><div>Regards,</div><div>Tomita</div><div><br></div><div>On 2013/08/12, at 16:35, Norman Goldstein &lt;<a href="mailto:normvcr@telus.net">normvcr@telus.net</a>&gt; wrote:</div><div><br class="Apple-interchange-newline"><blockquote type="cite">That's a nice, clean, valgrind run.<br>Something next to consider trying is in your debugger,<br>to put a "change" watch on the variable location<br>that should be const. &nbsp;You can set it to break<br>when the memory location changes value, and<br>then you can hopefully see who the culprit is.<br><br><br>On 08/11/2013 10:35 PM, Nozomu Tomita wrote:<br><blockquote type="cite">Dear all,<br><br>Thank you for the quick reply.<br>I tried valgrind, but (if my usage is correct) it found no error.<br>(as I didn't use "new" or "[]" operator, I guess this is not from memory handling in this code)<br><br>I could reduce my previous code...: <a href="http://pastebin.ca/2430872">http://pastebin.ca/2430872</a> ,<br>and its output is this: <a href="http://pastebin.ca/2430873">http://pastebin.ca/2430873</a> .<br><br>This code does a multiplication with a template class "wrap", for double and adouble.<br>Line 15-18 of the output corresponds to line 25-34 of the source, with D == adouble.<br>Here a and b changes after multiplication, in spite of its type "wrap&lt;const adouble&gt;"<br>(consequently its member is of type "const adouble").<br><br>In this output the results (A's) are not different for double and adouble,<br>but it will differ if a or b is used in calculation.<br><br>"make_pair(-A,-A)" at line 32 of the source may be important, because replacing it to<br>e.g. "make_pair(A,-A)" or "make_pair(-A,A)" changes output.<br><br>About valgrind, on Fedora on virtual machine (as I couldn't make valgrind work in Mac and Debian), with<br>$ valgrind -v ./a.out<br>outputted this: <a href="http://pastebin.ca/2430874">http://pastebin.ca/2430874</a><br><br>I got the same result in previous two environments and on Fedora above.<br><br>Thank you,<br>Tomita<br><br>On 2013/08/12, at 0:12, Norman Goldstein &lt;<a href="mailto:normvcr@telus.net">normvcr@telus.net</a>&gt; wrote:<br><br><blockquote type="cite">Perhaps running a memory checker, such as valgrind on linux, would be insightful?<br><br><br>On 08/11/2013 12:55 AM, Nozomu Tomita wrote:<br><blockquote type="cite">Dear all,<br><br>I'm writing 3-dimensional geometrical calculation, such as how long a line penetrates a box,<br>with templated class.<br><br>The problem is that my templated function returns different results for double and adouble,<br>and "const adouble" quantities seem to change in the middle of calculation.<br><br>I'm sorry for the mess of source code, but I couldn't pick out the exact place that harms...<br><br>My code <a href="http://pastebin.ca/2430586">http://pastebin.ca/2430586</a> is meant to do an identical calculation for both double and adouble,<br>checking whether a line that is parallel to z-axis and on (1/2, 1/2, 0), penetrates<br>a square (0,0,0)-(1,0,0)-(1,1,0)-(0,1,0).<br><br>That returns correctly true for double, but false for adouble.<br>Compiling this with -DDEBUG produces this output: <a href="http://pastebin.ca/2430588">http://pastebin.ca/2430588</a><br><br>Line 55 - 67 of this output correspond to line 173 - 216 of source with template argument Real==adouble.<br>The Odd thing is that although X and u (and its members) are declared as const,<br>they change during calculation, from line 57 (u == vector3(0(a), 0(a), 1(a)))<br>and line 59 (u == vector3(0(a), 0(a), 0(a))).<br><br><br>I tested this result for ADOL-C 2.4.1 in two environments:<br>* Debian 6.0.1,<br> &nbsp;with g++ (Debian 4.4.5-8) 4.4.5<br>* MacOS X 10.8.4,<br> &nbsp;with g++ i686-apple-darwin11-llvm-g++-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)<br><br><br>Thank you!<br><br>Tomita<br>_______________________________________________<br>ADOL-C mailing list<br><a href="mailto:ADOL-C@list.coin-or.org">ADOL-C@list.coin-or.org</a><br>http://list.coin-or.org/mailman/listinfo/adol-c<br><br></blockquote><br>_______________________________________________<br>ADOL-C mailing list<br><a href="mailto:ADOL-C@list.coin-or.org">ADOL-C@list.coin-or.org</a><br>http://list.coin-or.org/mailman/listinfo/adol-c<br></blockquote><br>_______________________________________________<br>ADOL-C mailing list<br><a href="mailto:ADOL-C@list.coin-or.org">ADOL-C@list.coin-or.org</a><br>http://list.coin-or.org/mailman/listinfo/adol-c<br><br></blockquote><br><br>_______________________________________________<br>ADOL-C mailing list<br><a href="mailto:ADOL-C@list.coin-or.org">ADOL-C@list.coin-or.org</a><br>http://list.coin-or.org/mailman/listinfo/adol-c</blockquote></div><br></body></html>