wmii crashes predictably when a second xrandr screen is added

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Start wmii with only a single screen connected to the computer, but 
with a "Virtual xxxx yyyy" setting in xorg.conf that yields enough space 
for two screens.
2. Connect a second screen.
3. Enable the second screen with e.g. "xrandr --output DVI-0 --left-of 
LVDS --auto"

What is the expected result? What do you see instead?
wmii crashes. When the second screen is connected at the time wmii starts, 
this problem does not occur, i.e. the second screen can be disabled/
enabled with xrandr without wmii crashing.

What version of the product are you using (wmii -v)? On what operating
system?
wmii-hg2585, ©2009 Kris Maglione
Debian testing
Linux <hostname> 2.6.30-2-686 #1 SMP Sat Sep 26 01:16:22 UTC 2009 i686 GNU/
Linux
xorg 7.4
xserver 1.6.5

Original issue reported on code.google.com by hur...@trash-mail.com on 5 Nov 2009 at 12:40

[GoogleCodeExporter]

I really don't have a way of testing this at the moment. Do you get a core 
dump? If
so, can you provide a stack trace? Is there any console output? This seems more
likely to be an abort than a crash.

Original comment by maglion...@gmail.com on 13 Nov 2009 at 12:11

[GoogleCodeExporter]

I also have this issue.  I have attached a core dump from the latest hg pull.  
I plan on trying to investigate this 
next week if I have time.  Anyway, here is the stack trace:

Program terminated with signal 11, Segmentation fault.
#0  0x0000000000422586 in frames_update_sel (v=0xf324b0) at view.c:174
174             foreach_frame(v, s, a, f)
(gdb) bt
#0  0x0000000000422586 in frames_update_sel (v=0xf324b0) at view.c:174
#1  0x0000000000422d84 in view_update (v=0xf324b0) at view.c:280
#2  0x0000000000417003 in init_screens () at main.c:223
#3  0x0000000000428522 in randr_screenchange (ev=0x7fff67300f80) at xext.c:75
#4  0x0000000000428359 in handle (e=0x7fff67300f80, h=0x643030, base=100) at 
xext.c:32
#5  0x00000000004283a3 in xext_event (e=0x7fff67300f80) at xext.c:46
#6  0x000000000040c944 in dispatch_event (e=0x7fff67300f80) at event.c:17
#7  0x000000000040d664 in check_x_event (c=0xf2b610) at event.c:356
#8  0x000000000042b0d5 in handle_conns ()
#9  0x000000000042b1b5 in ixp_serverloop ()
#10 0x0000000000417a28 in main (argc=0, argv=0x7fff67301350) at main.c:446

$ wmii -v
wmii-hg2594, ©2009 Kris Maglione

Original comment by tom5760@gmail.com on 18 Dec 2009 at 4:34

Attachments:

• wmii-153-core

[GoogleCodeExporter]

Bug still exists in wmii-0.9.2 (wmii-hg2718, ©2010 Kris Maglione)

I have absolute no idea what you doing in the macros at ./cmd/wmii/fns.h but if 
I replaced all macro calls (foreach_{area,column,frame}) it works fine.

But if I quit wmii I get an segfault anyway. In one of my replaced macros at 
./cmd/wmii/view.c:view_arrange on calling foreach_area. s < nscreens so 
a=v->areas[s] but __anext=a->next fails with segfault.

Sorry for such a bad description. I can't send a patch because it is full of 
ugly printf's. Hope this helps.

Original comment by nou...@gmail.com on 18 Jun 2010 at 1:44

[GoogleCodeExporter]

Can you provide a 'bt full' from the core dump?

Original comment by maglion...@gmail.com on 18 Jun 2010 at 2:37

[GoogleCodeExporter]

Sorry, I can reproduce my success from tonight. I added a diff with the 
replaced macros. I still get the segfault in view_arrange. But it fails when I 
added the screen via xrandr. Tonight, for whatever reason, it fails not until I 
quit wmii.

I hope my Backtrace is correct.

Original comment by nou...@gmail.com on 18 Jun 2010 at 12:53

Attachments:

• replacing_macros.patch
• gdbinfo

[GoogleCodeExporter]

This issue was closed by revision 45371d69c2.

Original comment by maglion...@gmail.com on 18 Jun 2010 at 2:17

• Changed state: Fixed

[GoogleCodeExporter]

Thanks for this fast fix. I tried the latest version of libixp and wmii from hg 
but it fails if I add a new screen anyway.

Original comment by nou...@gmail.com on 18 Jun 2010 at 2:54

Attachments:

• gdbinfo

[GoogleCodeExporter]

Try a clean build (either from a fresh checkout or after make clean). There's 
something wrong with that backtrace.

Original comment by maglion...@gmail.com on 18 Jun 2010 at 3:00