From: Malte M. <Mal...@cs...> - 2008-05-12 23:18:08
|
Hi, I had a look through the archives but couldn't find an answer to this. Using the tkagg backend (agg is fine) I get a segmentation fault doing a simple plot. gdb returns the following: 362 Point* ll_api() {return _ll;} Current language: auto; currently c++ (gdb) bt #0 0xb6fc1bac in PyAggImagePhoto (clientdata=0x0, interp=0x87a9430, argc=5, argv=0xbf97fc9c) at src/_transforms.h:362 #1 0xb712ea5c in TclInvokeStringCommand () from /usr/lib/libtcl8.4.so #2 0xb712ff05 in TclEvalObjvInternal () from /usr/lib/libtcl8.4.so #3 0xb7131015 in Tcl_EvalObjv () from /usr/lib/libtcl8.4.so #4 0xb73d34a6 in ?? () from /usr/lib/python2.5/lib-dynload/_tkinter.so snip This is matplotlib-0.91.2, python 2.5 on linux (opensuse 10.3) Cheers, Malte. |
From: Michael D. <md...@st...> - 2008-05-13 12:20:03
|
This looks like the same symptoms as this (unresolved) bug here: http://sourceforge.net/tracker/index.php?func=detail&aid=1949982&group_id=80706&atid=560720 Your gdb backtrace reveals that you have debugging symbols in matplotlib, so we've got a little more information now. Thanks. Since this crash is in an inlined C++ method, I would try forcing a clean rebuild of matplotlib (by deleting the build directory under the source tree) and rebuilding/reinstalling. Beyond that, I'm a little stumped. Could you run the following in gdb when the crash happens? p bboxo p bbox p bbox->_ll Cheers, Mike Malte Marquarding wrote: > Hi, > > I had a look through the archives but couldn't find an answer to this. > Using the tkagg backend (agg is fine) I get a segmentation fault > doing a simple plot. > gdb returns the following: > > 362 Point* ll_api() {return _ll;} > Current language: auto; currently c++ > (gdb) bt > #0 0xb6fc1bac in PyAggImagePhoto (clientdata=0x0, interp=0x87a9430, > argc=5, > argv=0xbf97fc9c) at src/_transforms.h:362 > #1 0xb712ea5c in TclInvokeStringCommand () from /usr/lib/libtcl8.4.so > #2 0xb712ff05 in TclEvalObjvInternal () from /usr/lib/libtcl8.4.so > #3 0xb7131015 in Tcl_EvalObjv () from /usr/lib/libtcl8.4.so > #4 0xb73d34a6 in ?? () from /usr/lib/python2.5/lib-dynload/_tkinter.so > snip > > This is matplotlib-0.91.2, python 2.5 on linux (opensuse 10.3) > > > Cheers, > Malte. > > ------------------------------------------------------------------------- > 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 > -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA |
From: Malte M. <Mal...@cs...> - 2008-05-13 23:41:41
|
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 |
From: Michael D. <md...@st...> - 2008-05-14 12:48:13
|
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 |
From: Malte M. <Mal...@cs...> - 2008-05-14 22:40:37
|
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... |
From: Malte M. <Mal...@cs...> - 2008-05-15 01:33:29
|
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... |
From: Malte M. <Mal...@cs...> - 2008-05-15 04:44:25
Attachments:
_tkagg.cpp.patch
|
Hi Attached is the the patch. It uses stringstream, so I don't know if it will work on all platforms. I am not a windows person ;-) I didn't read your email properly about the existence of "atoll", so as I am a c++er I am a bit more comfortable with stringstream. Cheers, Malte. |
From: Michael D. <md...@st...> - 2008-05-15 13:05:33
|
Yes, it looks like if it were an "unsigned int", we would have been okay. That looks like (essentially) what your patch does, but in a C++ idiom. I'll submit your patch and put a note out to the Windows guys to help test it. There's a good chance that if it compiles at all, it should work. Thanks for getting to the bottom of this. Cheers, Mike Malte Marquarding wrote: > Hi > > Attached is the the patch. It uses stringstream, so I don't know if it > will work on all platforms. I am not a windows person ;-) > I didn't read your email properly about the existence of "atoll", so > as I am a c++er I am a bit more comfortable with stringstream. > > Cheers, > Malte. > > > -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA |
From: Eric F. <ef...@ha...> - 2008-05-15 17:39:50
|
Michael Droettboom wrote: > Yes, it looks like if it were an "unsigned int", we would have been > okay. That looks like (essentially) what your patch does, but in a C++ > idiom. I'll submit your patch and put a note out to the Windows guys to > help test it. There's a good chance that if it compiles at all, it > should work. Mike, If you understand what the patch does, and if you know how to do it in a C idiom (or C++ for that matter) that is readable and that *will* compile and run, then I would suggest that you modify the patch accordingly instead of waiting to see if it *does* compile on whatever compiler versions the Windows people happen to have right now. Eric |
From: Michael D. <md...@st...> - 2008-05-15 18:21:57
|
Eric Firing wrote: > Michael Droettboom wrote: >> Yes, it looks like if it were an "unsigned int", we would have been >> okay. That looks like (essentially) what your patch does, but in a >> C++ idiom. I'll submit your patch and put a note out to the Windows >> guys to help test it. There's a good chance that if it compiles at >> all, it should work. > > Mike, > > If you understand what the patch does, and if you know how to do it in > a C idiom (or C++ for that matter) that is readable and that *will* > compile and run, then I would suggest that you modify the patch > accordingly instead of waiting to see if it *does* compile on whatever > compiler versions the Windows people happen to have right now. It does compile and run on gcc-3.4 and gcc-4.2 on Linux, and solves Matle's crash (which I was never able to reproduce myself), so I committed the patch (with only cosmetic changes) to SVN. It just needs to be verified under Visual Studio, which I don't personally have. Plus the whole Tcl thing where it encodes the pointer as a string of digits and then converts that back to an unsigned int gives me the heebie-jeebies, but I think we're stuck with that, for reasonable values of "stuck". Cheers, Mike -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA |
From: Eric F. <ef...@ha...> - 2008-05-15 18:00:16
|
Michael Droettboom wrote: > Yes, it looks like if it were an "unsigned int", we would have been > okay. That looks like (essentially) what your patch does, but in a C++ > idiom. I'll submit your patch and put a note out to the Windows guys to > help test it. There's a good chance that if it compiles at all, it > should work. Looks like the C idiom would almost have to use something like sscanf(argv[2], "%lu", tmpulong). Is it bad form to use this in C++? Is *anything* actually standardized in C++? How does one know whether something like stringstream is safe to use? The "ask someone to try it" approach is not very reassuring. Eric |
From: Michael D. <md...@st...> - 2008-05-15 18:17:34
|
qEric Firing wrote: > Michael Droettboom wrote: >> Yes, it looks like if it were an "unsigned int", we would have been >> okay. That looks like (essentially) what your patch does, but in a >> C++ idiom. I'll submit your patch and put a note out to the Windows >> guys to help test it. There's a good chance that if it compiles at >> all, it should work. > > Looks like the C idiom would almost have to use > something like sscanf(argv[2], "%lu", tmpulong). That is a reasonable alternative. > Is it bad form to use this in C++? > Is *anything* actually standardized in C++? The stringstream class used is in the C++ standard library. My concern is only based on Visual Studio not always adhering to it. In this case, it's a pretty safe bet it does -- it's a very core and long-standing piece of functionality. > How does one know whether something like stringstream is safe to > use? The "ask someone to try it" approach is not very reassuring. Barring more obvious documentation from Visual Studio (which may be mostly ignorance on my part) the only sure way to know is to try it. But it is in the specification and mentioned in Stroustrup, "C++: The Programming Language". Cheers, Mike -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA |