[ADOL-C] result seems to differ for double and adouble

Mon Aug 12 08:41:35 EDT 2013

Hello,

Thank you very much.
I tried to do that, and I think I found where overwriting occurs.

By compiling this code (modified for debugging) http://pastebin.ca/2430971
with
$ g++ -g -Wall -c -O0 -I${HOME}/adolc_base/include adolc_test.cc
$ g++ adolc_test.o ${HOME}/adolc_base/lib64/libadolc.a 
and
$ gdb a.out
and to copy & paste commands http://pastebin.ca/2430973 , gdb should go the place of the problem,
 "adub operator * ( const badouble& x, const badouble& y )" at line 1001 in adouble.cc.
 (I tested in my three environment that this gdb commands works)
The tail of gdb output is like this: http://pastebin.ca/2430975 (this is in Debian).
From this place, doing "n" gdb command several times changes what I declared as const.

This seems to me that, variable "a" and "b" in my code is stored at index 5 and 4 respectively, in global array  "globalTapeVars.store"  inside ADOL-C.
By several "n" command  above, changes "globalTapeVars.store[4]", namely "b".
The problem seems to be in "next_loc()" function.
As argument  x and y (for "adub operator *") are declared as const, it seems next_loc() should
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
consequently x is overwritten.

(The tail of gdb output at this point is http://pastebin.ca/2430984 (Debian).
please compare globalTapeVars.store[4] at the top and at the bottom,
and locations of variables x, y, locat at line 5,7,135.)

Regards,
Tomita

On 2013/08/12, at 16:35, Norman Goldstein <normvcr at telus.net> wrote:

> That's a nice, clean, valgrind run.
> Something next to consider trying is in your debugger,
> to put a "change" watch on the variable location
> that should be const.  You can set it to break
> when the memory location changes value, and
> then you can hopefully see who the culprit is.
> 
> 
> On 08/11/2013 10:35 PM, Nozomu Tomita wrote:
>> Dear all,
>> 
>> Thank you for the quick reply.
>> I tried valgrind, but (if my usage is correct) it found no error.
>> (as I didn't use "new" or "[]" operator, I guess this is not from memory handling in this code)
>> 
>> I could reduce my previous code...: http://pastebin.ca/2430872 ,
>> and its output is this: http://pastebin.ca/2430873 .
>> 
>> This code does a multiplication with a template class "wrap", for double and adouble.
>> Line 15-18 of the output corresponds to line 25-34 of the source, with D == adouble.
>> Here a and b changes after multiplication, in spite of its type "wrap<const adouble>"
>> (consequently its member is of type "const adouble").
>> 
>> In this output the results (A's) are not different for double and adouble,
>> but it will differ if a or b is used in calculation.
>> 
>> "make_pair(-A,-A)" at line 32 of the source may be important, because replacing it to
>> e.g. "make_pair(A,-A)" or "make_pair(-A,A)" changes output.
>> 
>> About valgrind, on Fedora on virtual machine (as I couldn't make valgrind work in Mac and Debian), with
>> $ valgrind -v ./a.out
>> outputted this: http://pastebin.ca/2430874
>> 
>> I got the same result in previous two environments and on Fedora above.
>> 
>> Thank you,
>> Tomita
>> 
>> On 2013/08/12, at 0:12, Norman Goldstein <normvcr at telus.net> wrote:
>> 
>>> Perhaps running a memory checker, such as valgrind on linux, would be insightful?
>>> 
>>> 
>>> On 08/11/2013 12:55 AM, Nozomu Tomita wrote:
>>>> Dear all,
>>>> 
>>>> I'm writing 3-dimensional geometrical calculation, such as how long a line penetrates a box,
>>>> with templated class.
>>>> 
>>>> The problem is that my templated function returns different results for double and adouble,
>>>> and "const adouble" quantities seem to change in the middle of calculation.
>>>> 
>>>> I'm sorry for the mess of source code, but I couldn't pick out the exact place that harms...
>>>> 
>>>> My code http://pastebin.ca/2430586 is meant to do an identical calculation for both double and adouble,
>>>> checking whether a line that is parallel to z-axis and on (1/2, 1/2, 0), penetrates
>>>> a square (0,0,0)-(1,0,0)-(1,1,0)-(0,1,0).
>>>> 
>>>> That returns correctly true for double, but false for adouble.
>>>> Compiling this with -DDEBUG produces this output: http://pastebin.ca/2430588
>>>> 
>>>> Line 55 - 67 of this output correspond to line 173 - 216 of source with template argument Real==adouble.
>>>> The Odd thing is that although X and u (and its members) are declared as const,
>>>> they change during calculation, from line 57 (u == vector3(0(a), 0(a), 1(a)))
>>>> and line 59 (u == vector3(0(a), 0(a), 0(a))).
>>>> 
>>>> 
>>>> I tested this result for ADOL-C 2.4.1 in two environments:
>>>> * Debian 6.0.1,
>>>>  with g++ (Debian 4.4.5-8) 4.4.5
>>>> * MacOS X 10.8.4,
>>>>  with g++ i686-apple-darwin11-llvm-g++-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)
>>>> 
>>>> 
>>>> Thank you!
>>>> 
>>>> Tomita
>>>> _______________________________________________
>>>> ADOL-C mailing list
>>>> ADOL-C at list.coin-or.org
>>>> http://list.coin-or.org/mailman/listinfo/adol-c
>>>> 
>>> 
>>> _______________________________________________
>>> ADOL-C mailing list
>>> ADOL-C at list.coin-or.org
>>> http://list.coin-or.org/mailman/listinfo/adol-c
>> 
>> _______________________________________________
>> ADOL-C mailing list
>> ADOL-C at list.coin-or.org
>> http://list.coin-or.org/mailman/listinfo/adol-c
>> 
> 
> 
> _______________________________________________
> ADOL-C mailing list
> ADOL-C at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/adol-c

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.coin-or.org/pipermail/adol-c/attachments/20130812/e6f51128/attachment.html>