I have a Perl Tk application.
If I move the main window so that it's not right up to the uppermost part of the screen, then the next time the following code is executed, the script fails:
$canvas_fimage_real=$canvas_fimage->Subwidget('canvas');
$canvas_fimage_real=$canvas_fimage unless $canvas_fimage_real;
my $canvas_id=$canvas_fimage_real->id;
my $canvas_fimage_photo=$main_window::main_window->Photo(-format=>'Window', -data=>oct $canvas_id );
And it fails with the following error message:
X Error of failed request: BadMatch (invalid parameter attributes)
Major opcode of failed request: 73 (X_GetImage)
Serial number of failed request: 2796
Current serial number in output stream: 2796
The script crashes at the Photo command.
How can I fix this?
Is this a window that is wholly on the screen? The snapshotting facility only works with what is visible on-screen (a low-level X11 condition; not negotiable). As such, you should file a bug report as the snapshot code shouldn't ask for things that it can't get.
Of course, if the window is fully on screen and you're getting that error message anyway, that's a serious problem. File a bug report in that case too!
Related
The message that is posted every time an execution fails is too verbose and creates too much noise. Is there a way to disable or hide it somehow? We have our own error messages within the scripts and don't need a red chunk of extra text displayed in the logs. Adding an error handler that will exit with code 0 is not an option because we still need the job to fail if a step fails.
That message is Rundeck standard output in case of failure (you can manipulate the loglevel but that doesn't affect the NonZeroResultCode last line, just the text from your commands/scripts), you can suggest that here. The rest are just workarounds as you mentioned.
This occurs even using the Quiet output.
I had a pyGObject app and I run that. all things work fine until on a button clicked signal I need to run a def. it has a long loop and I run that with the
def on_launch_btn_clicked(self,button):
_thread.start_new_thread(launch,["thread"])
def launch(thread):
lines_list = open("../line.txt").split()
for line in lines_list:
select = machinestate.objects.get(id=1)
if not select.pause:
#my process
else:
def pause_lcd()
return "pause" #it for come out of def and close thread but I don't know it close that or not
this loop is in another .py file
function it works like a charm, next I had a pause button it changes database pause field to True and my loop every iteration check database to saw what is changed. when it saw pause is True it run
def pause_lcd():
app = app_list[0]
app.pause_action()
I run Gtk app in this def
app_list = list()
def main(thread):
app = GUI()
app_list.append(app)
Gdk.threads_init()
Gtk.main()
in my GUI class I have pause_action method
def pause_action(self):
self.pause_btn.set_sensitive(True)
self.pause_btn.hide()
self.resume_btn.show()
when I clicked on pause button some time I got this error
[xcb] Unknown sequence number while processing queen
[xcb] Most likely this is a mulity-threaded client and XinitThreads has not been called
[xcb] Aborting, sorry about that
pyhton: ../../src/xcb_io.c:263 poll_for_event: Assertion '!xcb_xlib_threads_sequence_lost failed.
I had a bunch of thread side this threads like machine info, clock, machine temp and ...
what I do wrongs??
PS: this app run in a Django project and I use Django model in this it is an app of Django but it runs a Gtk app
I suspect that something with the XCB or the X11 server is wrong (bug). I received the same error message from different applications on a specific X server (using X11 over ssh).
Error message with emacs:
[xcb] Unknown sequence number while processing queue
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
emacs: xcb_io.c:263: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed.
Error message with eclipse:
[xcb] Unknown sequence number while processing queue
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
java: xcb_io.c:263: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed.
This Problem occurs on the RPi (3B+, Raspbian Buster) only. I run the program on my Mac without any problems.
Short description of my program:
After entering the mainloop, the program enters a second thread with another loop (call it requestloop) when the designated button is pressed. The requestloop can be left by pressing the button again. This requestloop requests a xml table via url every 10 seconds which is then parsed with ElementTree, sorted and displayed in a wx.grid.Grid. I use grid.ForceRefresh to make sure the grid is updated.
I hope the following snippet helps to understand the above:
def on_btnrun(self, event):
global run
if self.btnrun.Label == "Start":
run = True
thrupt = threading.Thread(target=self.thrupdate)
thrupt.start()
self.btnrun.SetLabel("Ende")
elif self.btnrun.Label == "Ende":
run = False
self.btnrun.SetLabel("Start")
def thrupdate(self):
while run is True:
reset()
self.grid.ClearGrid()
update(self.grid)
self.grid.ForceRefresh()
time.sleep(10)
Problem:
Now as mentioned in the title the whole wx Window freezes after passing the requestloop between roughly 5 and 20 times. This happens completely randomly, I could not find any regularities. The program keeps running though, for it still prints the output in the terminal every cycle (I added this function for testing).
When I now open another window (eg. menu dropwdown) which lays over the wx Window it will be copied onto the wx Window and stay there after I closed it.
Here are some Images to better understand what I mean (ignore all other widgets that I didn't mention, they are just nonfunctional placeholders).
Image of the wx Window before it freezes
Image of the wx Window after it freezes
Image of the wx Window after opening and closing the dropdown menu
Extra-Info: while building wxPython on the RPi I got some warnings and everytime I run the program I get the following one (it says the actual time instead of time):
(program.py:1666): Gtk-Critical **: time: gtk_distribute_natural_allocation: assertion ‚extra_space >= 0‘ failed
Question:
I have no idea why any of this happens. Is wxPython not stable on Raspbian? Or did the build partly fail? Or is the RPi not having enough rendering capacity?
Solved it by using wx.CallAfter in the details of the update() method.
The error popup with the following error message comes on the screen repeatedly when application is in idle state (no user activity is performed).
Error occurred on client: (TypeError): Unable to get property 'iterator_0' of undefined or null reference.
number: -2146823281
at handleEvent_206....EF34544...cache.html
at dispatchEvent_0..EF34544...cache.html
at sucess_184 ..
..
Can anyone give some pointers to navigate to the problamatic area in the code?
The fact that you're getting it repeatedly is probably due to the fact that you're performing an action on a timer (i.e. perform repeatedly an action).
From the small snippet you've shown, I don't think there's anything we can deduce. Do you have a larger stacktrace? It is still possible the error is in your own code (trying to invoke iterator() on a null object).
I am running the following MATLAB code on a system with one GTX 1080 and a K80 (with 2 GPUs)
delete(gcp('nocreate'));
parpool('local',2);
spmd
gpuDevice(labindex+1)
end
reset(gpuDevice(2))
reset(gpuDevice(3))
parfor i=1:100
SingleGPUMatlabCode(i);
end
The code runs for around a second. When I rerun the code after few seconds. I get the message:
Error using parallel.gpu.CUDADevice/reset
An unexpected error occurred during CUDA execution. The
CUDA error was:
unknown error
Error in CreateDictionary
reset(gpuDevice(2))
I tried increasing TdrDelay, but it did not help.
Something in your GPU code is causing an error on the device. Because the code is running asynchronously, this error is not picked up until the next synchronisation point, which is when you run the code again. I would need to see the contents of SingleGPUMatlabCode to know what that error might be. Perhaps there's an allocation failure or an out of bounds access. Errors that aren't correctly handled will get converted to 'unknown error' at the next CUDA operation.
Try adding wait(gpuDevice) inside the loop to identify when the error is occurring.
If either device 2 or 3 are the GTX1080, you may have discovered an issue with MATLAB's restricted support for the Pascal architecture. See https://www.mathworks.com/matlabcentral/answers/309235-can-i-use-my-nvidia-pascal-architecture-gpu-with-matlab-for-gpu-computing
If this is caused by the Windows timeout, you would see a several second screen blackout.