Re: [Matplotlib-users] [ExternalEmail] Re: tkinter segv under opensuse 10.3

[Malte M. <Mal...@cs...>]

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
> Mal...@cs...
>
>
>
>
> ---------------------------------------------------------------------- 
> ---
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Malte Marquarding
Mal...@cs...