| ID: | 4479 |
| From: | Majenko Technologies <ma...@majenko.co.uk> |
| Date: | Tue, 27 Oct 2020 11:28:50 +0000 |
| Subject: | Re: [pcb-rnd] Strange lockups |
| in-reply-to: | 4478 from ge...@igor2.repo.hu |
--00000000000084052205b2a55afb Content-Type: text/plain; charset="UTF-8" I have nailed it down now. It's not PCB-RND but the interaction between PCB-RND and my gaf-project control panel. PCB-RND is spewing out millions of ** (uPR3b.lht:33145): WARNING **: 11:26:47.463: invalid source position for vertical gradient which I think is down to my selected GTK theme more than PCB-RND. Those are clogging up an input stream and blocking, making everything die. On Tue, Oct 27, 2020 at 11:25 AM <gedau@igor2.repo.hu> wrote: > > > On Tue, 27 Oct 2020, Majenko Technologies wrote: > > >I have recently been experiencing a couple of random lockups with > PCB-RND. I > >haven't yet got to the bottom of it, and it's proving hard to replicate. > >It always happens when navigating a menu though, and it freezes the whole > >window manager with the menu half displayed (the *whole* window manager - > >can't select any other windows, or anything). To do anything I have to > kick > >out to a console and kill pcb-rnd at which point my X session becomes > >responsive again. > > > >I don't know yet whether this is just a quirk with my system or something > in > >PCB-RND. I'll keep digging and give more detail as I find it, but this is > >really just a heads up that there might be something up with menus. Once I > >can replicate it more reliably I can try various options like different > HIDs > >to see if that makes a difference. > > > If the whole WM freezes, you most likely have something real bad outside > of pcb-rnd: in a UNIX system we expect a process can crash, go in infinite > loop, do rnadom stupid things, but that shouldn't affect global resources > and other processes. Of course that doesn't mean we don't have a bug on > our side that triggers it, but I can't imagine a situation where it's > legitimate that a pcb-rnd bug hangs your whole WM. > > If you did not click on any menu item that'd execute an action, only > opened menus and moved around, you did not tear off any menu to cause it, > then it's even further away from pcb-rnd: both in gtk and in lesstif we > replicate the internal menu structure into the toolkit's menu system and > from then on we leave the toolkit to handle the menu system. > > We only touch the toolkit's menu system again when you change some config > setting that has a checkbox in a menu or if we need to insert/remove menu > items. But if you are not doing anything that changes states, it's all gtk > and the WM in your case. > > Please try these, when you have the lockup and switched to the console: > > - look at CPU consumption of pcb-rnd itself > > - if CPU is spinning on 100% on your pcb-rnd process, also look at the > memory footprint; the important aspect is not the current absolute memory > usage, but whether it's constantly growing or not > > - configure with --debug and attach a gdb to the running process when you > already have the lockup and capture a backtrace; if you can produce this > multiple times, please always save a backtrace, so we see if it's always > the same > > TIA, > > Igor2 -- *Matt Jenkins* Majenko Technologies https://majenko.co.uk --00000000000084052205b2a55afb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">I have nailed it down now. It's not PCB-RND but the in= teraction between PCB-RND and my gaf-project control panel.<div><br></div><= div>PCB-RND is spewing out millions of=C2=A0</div><div><br></div><div>** (u= PR3b.lht:33145): WARNING **: 11:26:47.463: invalid source position for vert= ical gradient<br></div><div><br></div><div>which I think is down to my sele= cted GTK theme more than PCB-RND. Those are clogging up an input stream and= blocking, making everything die.</div></div><br><div class=3D"gmail_quote"= ><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Oct 27, 2020 at 11:25 AM <= ;<a href=3D"mailto:gedau@igor2.repo.hu">gedau@igor2.repo.hu</a>> wrote:<= br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e= x;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br> <br> On Tue, 27 Oct 2020, Majenko Technologies wrote:<br> <br> >I have recently been experiencing a couple of random lockups with PCB-R= ND. I<br> >haven't yet got to the bottom of it, and it's proving hard to r= eplicate.<br> >It always happens when navigating a menu though, and it freezes the who= le<br> >window manager with the menu half displayed (the *whole* window manager= -<br> >can't select any other windows, or anything).=C2=A0 To do anything = I have to kick<br> >out to a console and kill pcb-rnd at which point my X session becomes<b= r> >responsive again.<br> ><br> >I don't know yet whether this is just a quirk with my system or som= ething in<br> >PCB-RND. I'll keep digging and give more detail as I find it, but t= his is<br> >really just a heads up that there might be something up with menus. Onc= e I<br> >can replicate it more reliably I can try various options like different= HIDs<br> >to see if that makes a difference.<br> <br> <br> If the whole WM freezes, you most likely have something real bad outside <b= r> of pcb-rnd: in a UNIX system we expect a process can crash, go in infinite = <br> loop, do rnadom stupid things, but that shouldn't affect global resourc= es <br> and other processes. Of course that doesn't mean we don't have a bu= g on <br> our side that triggers it, but I can't imagine a situation where it'= ;s <br> legitimate that a pcb-rnd bug hangs your whole WM.<br> <br> If you did not click on any menu item that'd execute an action, only <b= r> opened menus and moved around, you did not tear off any menu to cause it, <= br> then it's even further away from pcb-rnd: both in gtk and in lesstif we= <br> replicate the internal menu structure into the toolkit's menu system an= d <br> from then on we leave the toolkit to handle the menu system.<br> <br> We only touch the toolkit's menu system again when you change some conf= ig <br> setting that has a checkbox in a menu or if we need to insert/remove menu <= br> items. But if you are not doing anything that changes states, it's all = gtk <br> and the WM in your case.<br> <br> Please try these, when you have the lockup and switched to the console:<br> <br> - look at CPU consumption of pcb-rnd itself<br> <br> - if CPU is spinning on 100% on your pcb-rnd process, also look at the <br> memory footprint; the important aspect is not the current absolute memory <= br> usage, but whether it's constantly growing or not<br> <br> - configure with --debug and attach a gdb to the running process when you <= br> already have the lockup and capture a backtrace; if you can produce this <b= r> multiple times, please always save a backtrace, so we see if it's alway= s <br> the same<br> <br> TIA,<br> <br> Igor2</blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D= "ltr" class=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><b>M= att Jenkins</b><div>Majenko Technologies</div><div><a href=3D"https://majen= ko.co.uk" target=3D"_blank">https://majenko.co.uk</a></div></div></div></di= v></div> --00000000000084052205b2a55afb--
Reply subtree:
4479 Re: [pcb-rnd] Strange lockups from Majenko Technologies <ma...@majenko.co.uk>