Hi,
we were on the right track just the inverse. The number of argv[4] is
bigger then MAX_LONG on 32bit.
So what I did is:
unsigned long tmplong;
std::stringstream ss;
ss.str(argv[4]);
ss >> tmplong;
bboxo = (PyObject*)tmplong;
Now it works.
Also, I will change all other atol()'s to stringstream, we are c++
er's anyway.
I will check out the svn and send a patch. Where do I send it to?
Cheers,
Malte
On 15/05/2008, at 8:40 AM, Malte Marquarding wrote:
> Hi,
>
> unfortunately 32-bit ;-) I tried digging around, but I don't know
> much about tcl/tk. Seeing a char string argv atol'ed into a pointer
> address left me with an uncomfortable feeling...
> Anyway her is the argv value
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0xb7c516c0 (LWP 5638)]
> 0xb6f4500e in PyAggImagePhoto (clientdata=0x0, interp=0x87396f0,
> argc=5,
> argv=0xbfc8874c) at src/_transforms.h:362
> 362 Point* ll_api() {return _ll;}
> Current language: auto; currently c++
> (gdb) p argv[4]
> $1 = 0x895d0f0 "3085736160"
> (gdb) p bboxo
> $2 = (PyObject *) 0x7fffffff
>
> The cast doesn't seem to work.
>
> Cheers,
> Malte
>
> On 14/05/2008, at 10:47 PM, Michael Droettboom wrote:
>
>> Ouch! The way that pointer is obtained is really weird (though I
>> believe it is a common idiom in Tcl extensions):
>>
>> PyAggImagePhoto(ClientData clientdata, Tcl_Interp* interp,
>> int argc, char **argv) {
>> ...
>> bboxo = (PyObject*)atol(argv[4]);
>> if (bboxo != Py_None) {
>> bbox = (Bbox*)bboxo;
>>
>> That means the pointer comes to us encoded as a string of digits,
>> which gets converted to an integer, cast to a (PyObject*), and then
>> cast to a (Bbox*) (which is a subclass of PyObject, in the C-object-
>> oriented sense). That's just one of those things you'd rather not
>> be doing ;)
>>
>> Are you running the 64-bit version of OpenSUSE by any chance? That
>> might explain this if the atol call is overflowing. That's only
>> theoretical, as I think it *should* work. atol is supposed to
>> return a "long", which is supposed to be 64-bit on a 64-bit Linux
>> machine. Could you try replacing "atol" with "atoll", recompile
>> and see what happens? Do you get any warnings during compilation
>> of _tkagg.cpp?
>>
>> Failing that, it would be useful, I suppose, to print out "argv[4]"
>> from the debugger.
>>
>> Thanks for helping with this. Hopefully we're honing in on
>> something.
>>
>> Mike
>>
>> Malte Marquarding wrote:
>>> Hi,
>>>
>>> The segv also occurs in matplotlib-0.90.1. A clean build doesn't
>>> help.
>>>
>>> Here is the gdb output, looks like something is pointing into
>>> nirvana..
>>>
>>> (gdb) p bboxo
>>> $1 = <value optimized out>
>>> (gdb) p bbox
>>> $2 = (Bbox *) 0x7ffffffb
>>> (gdb) p bbox->_ll
>>> Cannot access memory at address 0x7ffffffb
>>>
>>> Cheers,
>>> Malte
>>>
>>> On 13/05/2008, at 10:19 PM, Michael Droettboom wrote:
>>>
>>>> p bboxo
>>>> p bbox
>>>> p bbox->_ll
>>>
>>>
>>>
>>>
>>>
>>
>> --
>> Michael Droettboom
>> Science Software Branch
>> Operations and Engineering Division
>> Space Telescope Science Institute
>> Operated by AURA for NASA
>>
>
> Malte Marquarding
> [EMAIL PROTECTED]
>
>
>
>
> ----------------------------------------------------------------------
> ---
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Matplotlib-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Malte Marquarding
[EMAIL PROTECTED]
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Matplotlib-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
