On 5 December 2006 at 16:13, Michael Hanke wrote:
| Hi,
| 
| On Tue, Dec 05, 2006 at 08:32:54AM -0600, Dirk Eddelbuettel wrote:
| > 
| > Moin,
| > 
| > On 5 December 2006 at 14:29, Michael Hanke wrote:
| > | Hi Dirk,
| > | 
| > | On Tue, Dec 05, 2006 at 06:36:53AM -0600, Dirk Eddelbuettel wrote:
| > | > | And python dies :(
| > | > 
| > | > Not for me. Currnetly the R window is 'behind' Emacs and the (KDE) 
konsole
| > | > (xterm emulator) and I can happily replot:
| > | Replotting works for me as well, but python dies if the plot window
| > | comes back to foreground again (no need to replot anything). Actually I
| > | do not know what process is dying, but the python interpreter is heavily
| > | affected.
| > 
| > Ah. Didn't try that. Now I'll have to wait til I get back home from work :-/
| >  
| > | > All on testing too.  Not a bug in R as far I can tell (and the other 
way to
| > | > tell is to open a file device (png(), pdf(), .... in R, not sure what 
the RPy
| > | > way is) and plot there.
| > | Strange.
| > | 
| > | This is obviously not an R bug. I can do all this with plain R and
| > | everything is fine. I tested i386 sarge, i386 and amd64 etch.
| > 
| > I think we'd need something reproducible before we can and pester Greg [ rpy
| > upstream ] with this. We both agree that R is innocent in this.
| Right. However, it seems to me that whatever happens, happens in some
| place like the eventloop of the plotting window. Running python with strace 
| reveals no additional call between 'everything just works' and the crash when
| moving the partially hidden window.
| 
| > | But doing it from python with rpy segfaults on both testing machines,
| > | but *not* on sarge.
| > | 
| > | > You may need to tweak your window manager, though....
| > | Well, I have no clue what I should tweak. I'm using the package defaults
| > | on all machines and they work well for all other windows. 
| > | 
| > | BTW: I tried to run it remotely from the sarge machine (connected to 
amd64 
| > | etch via ssh) therefore using a different xserver and the *same* window 
manager 
| > | that proved to work when running rpy locally. The bug is still present, 
but the
| > | error message is slightly different:
| > | 
| > |    *** caught segfault ***
| > |   address 0x16e8790, cause 'invalid permissions'
| > 
| > That's weird one too. 
| > 
| > Could it be something having to with X11 / modules / permission / 
accelerated
| > X11 / ... ?
| That's all standard as well. The sarge Xserver (xfree) is using plain vesa,
| while both etch machine use the closed-source Nvidia module (with xorg). But 
the
| window crashes using both xservers, so we cannot easily put the blaim on
| Nvidia. Also, running other (even OpenGL) apps works just fine (also via
| ssh on both xservers).
| 
| Just to be sure: I tried to reproduce this bug on another machine
| running etch (i386), xorg (with open-source ati driver). Same bug,
| python dies as soon as I move the half-hidden window.
| 
| Here is what I used for strace:
| 
|       [EMAIL PROTECTED]:~$ cat rpytest.py
|       import time
|       from rpy import *
| 
|       x = range(0, 10)
|       y = [ 2*i for i in x ]
|       r.plot_default(x, y)
| 
|       time.sleep(30)
| 
| 
| And here is the last part of the strace output:
| 
|       [EMAIL PROTECTED]:~$ strace python rpytest.py       
| 
|       [very long part stripped]
| 
|       rt_sigaction(SIGINT, {0x80e4ca0, [], 0}, {0xb70fb620, [INT], 
SA_RESTART}, 8) = 0
|       futex(0x859d638, FUTEX_WAKE, 1)         = 0
|       futex(0x81b98c8, FUTEX_WAKE, 1)         = 1
|       select(0, NULL, NULL, NULL, {30, 0}Error during wrapup: C stack usage 
is too close to the limit
| 
|        *** caught segfault ***
|       address (nil), cause 'memory not mapped'
| 
| 
| Please notice the select call which stems from the sleep function.
| Between this call and the crash were several seconds. It crashed exacly
| when I started to move the window.

Excellent work. Let me just re-confirm this once I get home this evening. It
does look like something is wrong when it comes redrawing the windows, so it
is probably the Python-to-R-and-back interface as we both agree that R itself
ot probably not to blame.  I'll CC Greg now as an early heads-up

Greg: the whole story is at http://bugs.debian.org/401670 -- Michael found
that if a (partially or fully) hidden plot window owned by R and spawned from
RPy comes to the fore, R takes a hard landing and crashes.  Let us know if
you have questions, but the mail thread between Michael and myself is fully
in the archive.
 
Dirk

-- 
Hell, there are no rules here - we're trying to accomplish something. 
                                                  -- Thomas A. Edison


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to