Vadim Konovalov wrote:
>
>>> I started debug session and, after quite long run debugger stopped
>>> at the same place where non-debuggung executable stopped.
>>>
>>> Please see the 300Kbytes screenshot at
>>> http://vkonovalov.ru/files-exchange/clisp-2.41-deb.error.jpg
>>>
>> "congratulations, I suppose"...
>> you've got yourself corrupted memory.
>> if you are lucky, this could be uncovered by a DEBUG_GCSAFETY build, see
>> http://clisp.cons.org/impnotes/gc-safety.html
>> if you are not that lucky, you will have to resort to "printf" grudge
>> work.
>
>
>
> this is tricky for me, as a novice in clisp.
>
> however, when looking closer into the MSVC debug session, the source
> of offending 0x00000a09 is in the pr_cclosure_lang (io.d)
>
> Lines near the call in the debugger show (please see my few [vk]
> comments) :
addition: lambda_list_p equals to 0 and documentation_p also equals 0
'last' receives -2 by the statement
var uintL last = Cclosure_last_const(*obj_);
*obj is seemingly okay...
'end' receives -2 because of this 'last' having -2
If this does not make obvious sence, okay, I'll try to figure out things
in a slow way later...
>
> ....
> (inside the pr_cclosure_lang function)
> ....
> var uintL pos = 0;
> var bool lambda_list_p = ccv_flags_lambda_list_p(ccv_flags);
> var bool documentation_p = ccv_flags_documentation_p(ccv_flags);
> var uintL end = last - lambda_list_p - documentation_p;
> if (end != (uintL)-1)
> [vk] the 'end' variable equals '-2' (rather 4294967294, or FFFFFFE)
> here and do not pass unequality check...
> [vk] isn't the source of the error?
> for (; true; pos++) {
> prin_object(stream_,TheCclosure(*obj_)->clos_consts[pos]);
> [vk] !!! the call above has 0x00000a09 as its 2nd argument; pos==1 at
> this moment...
> JUSTIFY_LAST(pos==end);
> if (pos==end) break; [vk] because (uintL)-2 is way too high the
> look will be for many iterations.
> JUSTIFY_SPACE; /* print one Space */
> }
>
> .......
>
> sorry if my vision is too naive.
>
>>
>> I don't think so (I think you are confusing cygwin with mingw).
>
>
> looking into output of 'clisp --version' I see lines
>
> gcc -mno-cygwin -O2 ..... -L/usr/local/lib /usr/local/lib/libiconv.a
> libcharset.a
>
> ... which makes me think that its easy to confuse mingw and cygwin :) :)
>
>
>> note that the mingw version is likely to be faster than the msvc
>> version because clisp uses some assembly with gcc but not with msvc.
>
>
>
> this makes much sence, thanks for the information.
>
> I had intentions to link with other LIBS already compiled by MSVC++,
> but, indeed, those could be compiled with different compilers.
>
> Thank you a lot for the provided help so far.
>
> Best regards,
> Vadim.
>
>
|