well, that still doesn't explain the segfaults. NaNs shouldn't cause
matplotlib to crash upon saving. I would still be interested in a
stacktrace.
Ben
On Thu, Mar 19, 2015 at 1:27 PM, Gabriele Brambilla <
gb.gabrielebrambi...@gmail.com> wrote:
> Actually Paul Hobson was right.
>
> Now it works.
Actually Paul Hobson was right.
Now it works.
Thanks
Gabriele
On Thu, Mar 19, 2015 at 1:19 PM, Benjamin Root wrote:
> The warnings probably have nothing to do with the issue at hand. Try this.
> Install the package "faulthandler" and add the appropriate lines to your
> Bdipoly.py script and r
The warnings probably have nothing to do with the issue at hand. Try this.
Install the package "faulthandler" and add the appropriate lines to your
Bdipoly.py script and run it again. That way, we can get a traceback and
find out where it is segfaulting from.
http://faulthandler.readthedocs.org/en
What happens when you edit your program to avoid dividing by zero?
-p
—
Sent from Mailbox
On Thu, Mar 19, 2015 at 10:14 AM, Gabriele Brambilla
wrote:
> Hi guys,
> I don't understand why now, after I save an image when it is prompted out,
> the image is not saved and it closes automatically a
This is a bit of a surprise. Sounds like it could have something to do with
matplotlib's build, or that of some of its dependencies, so may need
reporting to Gentoo once we've dug a little further. It could be a really
tricky one to diagnose without being able to reproduce locally, but - is
the loo
It is a problem with the dialog, if you set the option DontUseNativeDialog.
then it works fine.
I guess that the problem is with Ubuntu 11.10.
On Mon, Mar 12, 2012 at 5:37 PM, Ray Osborn wrote:
> I think that QtGui.QFileDialog.getSaveFileName returns a tuple, the first
> element of which is the
I think that QtGui.QFileDialog.getSaveFileName returns a tuple, the first
element of which is the file name. You can ignore the second element by using:
fname, _ = QtGui.QFileDialog.getSaveFileName(self, 'Save file',
'/home/untitled.png', 'Images (*.png *.xpm *.jpg)')
Ray
On Mar 12, 2012, at 4
On Mon, Mar 12, 2012 at 4:30 PM, Sourabh Bajaj wrote:
> I am getting a segmentation fault when I try to declare a new image name. I
> can replace a existing image correctly. Why am I getting the error at the
> getSaveFileName dialog ??
[...]
> fname = QtGui.QFileDialog.getSaveFileName(self, 'Save
>
> Can you get us a gdb backtrace?
>
> Type "gdb python" at the prompt, then at the gdb prompt, type "r
> /usr/bin/ipython -pylab". After it segfaults, type "bt" to get a
> backtrace, and send the output to this list.
>
> Mike
>
> On 10/01/2010 07:04 AM, Eric Emsellem wrote:
> > Hi
> >
>
Can you get us a gdb backtrace?
Type "gdb python" at the prompt, then at the gdb prompt, type "r
/usr/bin/ipython -pylab". After it segfaults, type "bt" to get a
backtrace, and send the output to this list.
Mike
On 10/01/2010 07:04 AM, Eric Emsellem wrote:
> Hi
>
> I just upgraded to opensu
I committed a slightly tighter version of this that uses a rectangle
based on the size of the image plus a border to accomodate the exact
marker size. Probably makes very little difference, but I suppose if
there was a dense field of markers outside of view, this might speed
things up a bit mo
On Wed, Sep 23, 2009 at 10:15 PM, John Hunter wrote:
> On Wed, Sep 23, 2009 at 6:47 PM, Mike Nicolls wrote:
>> I've encountered a segmentation fault using the Agg backend when making
>> and saving a png plot. The segmentation fault does not seem to occur
>> under different backends (e.g. Cairo).
On Wed, Sep 23, 2009 at 6:47 PM, Mike Nicolls wrote:
> I've encountered a segmentation fault using the Agg backend when making
> and saving a png plot. The segmentation fault does not seem to occur
> under different backends (e.g. Cairo).
>
> The sequence of commands amounts to making a plot, set
I'm using 'xpdf' now, I think it must be ghostscript acting up. I only need
eps output infrequently so I'll stick with this workaround for the moment.
On Mon, Sep 7, 2009 at 4:28 AM, Jae-Joon Lee wrote:
> I cannot reproduce this error.
> And I'm not sure if this is a bug in matplotlib or ghostsc
I cannot reproduce this error.
And I'm not sure if this is a bug in matplotlib or ghostscript.
You may try to use different distiller.
pl.rc('ps', usedistiller="xpdf")
In my machine, both ghostscript and xpdf option works fine.
But my gs version is different than yours
GPL Ghostscript 8.61 (2007
Anyone else have ideas on how to display large images?
Thanks,
Adam
--
View this message in context:
http://www.nabble.com/Segmentation-fault-using-imshow-on-large-image-tp23207792p24152022.html
Sent from the matplotlib - users mailing list archive at Nabble.com.
-
Can you provide a standalone script that causes the segfault so we can
try to reproduce? Backtraces from gdb and valgrind "memcheck" logs
would also be helpful.
Mike
Kazansky, Stella (SKAZANSK) wrote:
>
> Hello,
> I am not sure that matplotlib is the cause, we are looking for it, but
> we ar
Bugzilla from tkjacob...@gmail.com wrote:
>
> Hi
>
> It could be that you just have to much data for the stack. You can see/set
> your stack size with ulimit -s (on linux/solaris at least). Try to set it
> to
> unlimited:
> ulimit -s unlimited
>
> This has solved similar problems for me in
A 1x1 array reproduces the error:
milkyway /data/glimpseii $ gdb /usr/local/python/bin/python
GNU gdb Red Hat Linux (6.3.0.0-1.159.el4rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or d
Hi
It could be that you just have to much data for the stack. You can see/set
your stack size with ulimit -s (on linux/solaris at least). Try to set it to
unlimited:
ulimit -s unlimited
This has solved similar problems for me in the past.
Best Regards
Troels Kofoed Jacobsen
On Saturday 25 Apr
On Sat, Apr 25, 2009 at 9:53 AM, Adam Ginsburg
wrote:
> Yep, I'm running on a 64 bit machine. I've been dealing with larger
> than 4GB data files in IDL, but I'd rather use python/numpy/matplotlib
> if possible.
>
> Here's the gdb session. The error didn't happen in imshow, only when
> I specifi
Yep, I'm running on a 64 bit machine. I've been dealing with larger
than 4GB data files in IDL, but I'd rather use python/numpy/matplotlib
if possible.
Here's the gdb session. The error didn't happen in imshow, only when
I specified show(); I guess that means I must have had ioff() set
although
On my machine (32-bit Fedora 10 with 2GB RAM), it chugs along swapping
for a lng time and then fails with a Python MemoryError exception --
which is at least reasonable.
I suspect you're running on a 64-bit machine and we're running into some
sort of non-64-bit-clean issue. We try to be 64
Thanks for the report.
This issue is actually already fixed in matplotlib SVN as of r6283:
http://matplotlib.svn.sourceforge.net/viewvc/matplotlib?view=rev&revision=6283
You can use the above patch to patch your local copy if you don't want
to install entirely from SVN.
Mike
Philipp Lies wrot
Great. You may still want to let the scisoft guys know about this so
others won't hit up against it.
Cheers,
Mike
Antonino Cucchiara wrote:
> Thanks,
> I just had to replace the /usr/lib/libiconv.2.dylib with the one I
> have in /sw/lib/ directory .
> Now the GTK, GTKAgg backend work.
>
> Nin
Thanks,
I just had to replace the /usr/lib/libiconv.2.dylib with the one I have
in /sw/lib/ directory .
Now the GTK, GTKAgg backend work.
Nino
Michael Droettboom wrote:
> You could try rebuilding matplotlib yourself. There are some OS-X
> directions here:
>
> http://www.astro.washington.edu/
You could try rebuilding matplotlib yourself. There are some OS-X
directions here:
http://www.astro.washington.edu/owen/BuildingMatplotlibForMac.html
This may mean, however, that it won't play nice with other parts of
scisoft. But this really is a matter of how and where scisoft was built
(w
Is there anything I can do to update it by myself in the meanwhile?
Thanks,
Nino
Michael Droettboom wrote:
> It looks like matplotlib was built for a different version of iconv than
> what you have on your machine. This may be a scisoft packaging problem,
> you may want to bring this question t
It looks like matplotlib was built for a different version of iconv than
what you have on your machine. This may be a scisoft packaging problem,
you may want to bring this question to their attention. Perhaps the
version of OSX that scisoft was built on/for is different than what
you're runni
Hi Mike,
I re-install the astronomy scisoft package and now the segmentation
fault is not anymore present when I import matplotlib.mathtext.
But when I import pylab I have the following error.
I think it's something related with my backend choise. I tried to change
all the GUI possibilities in
We need some more information.
Can you set "verbose.level" to "debug-annoying" in your
~/.matplotlib/matplotlibrc file?
Also, if you have the development tools (XCode) installed on your mac,
can you run python in gdb?
> gdb python
GNU gdb Red Hat Linux (6.3.0.0-1.153.el4_6.2rh)
Copyright 2004
I decided that the scipy superpack might be at fault so I installed
numpy 1.02 from the macpython packages and
then reinstalled MPL 0.90.0 from the macpython packages and now TkAgg
works. Also scipy still seems to work.
So apparently Fonnesbeck's build of scipy superpack has a problem
with
Hi,
In 10/24/06, John Hunter <[EMAIL PROTECTED]> wrote:
> > "Matthew" == Matthew Brett <[EMAIL PROTECTED]> writes:
>
> Matthew> I attach a stack trace in case it's helpful. Any
> Matthew> pointers on where I should go for debugging further?
For completeness - it was specific to the W
> "Matthew" == Matthew Brett <[EMAIL PROTECTED]> writes:
Matthew> I attach a stack trace in case it's helpful. Any
Matthew> pointers on where I should go for debugging further?
Hey Matthew
See the instructions in SEGFAULTS in the root mpl dir -- it will tell
you how to proceed to ge
34 matches
Mail list logo
