Tested that with both 5.3 and 7.9 version. The underlying problem is in src/rxvtd.C, where due to a unsuccesful call to chdir() for the client, it calls the err method of the current object, which then frees "this". Walk through roland@ferrari ~ $ urxvtd& [1] 643 roland@ferrari ~ $ rxvt-unicode daemon listening on /home/roland/.rxvt-unicode-ferrari. roland@ferrari ~ $ mkdir /tmp/foo && cd /tmp/foo && chmod -x . && urxvtc *** glibc detected *** double free or corruption (!prev): 0x00000000006100d0 ***[1]+ Abgebrochen urxvtd (wd: ~) (wd now: /tmp/foo) roland@ferrari /tmp/foo $ Oh, this happens also if the server is started from within this directory. (Note: Found with Coverity)
can't reproduce that. Can you give me a emerge --info please?
Created attachment 94311 [details] Output of emerge --info
Steps to reproduce: 1. make a new directory, lets say foo: mkdir foo 2. cd in that directory: cd foo 3. start the urxvtd, if not done already: urxvtd & 4. start the client urxvtc: urxvtc Results as above, crash...
(Again, forgotten setp 3...) Steps to reproduce: 1. make a new directory, lets say foo: mkdir foo 2. cd in that directory: cd foo 3. make current directory not executable: chmod -x . 4. start the urxvtd, if not done already: urxvtd & 5. start the client urxvtc: urxvtc Results as above, crash...
Yes, these steps you allready showed in the bug-report itself. I can't reproduce the crash. urxvtd hungs but doesn't crash on my system. It crashes after I press Ctrl-D on the shell.
Well, you are then lucky not having an immediate crash. But hanging up will then close other urxvtc's also, and thats not the intended behaviour. The underlying reason is, that the server object gets created via "new server (...)", but any time it calls his method server::err, it just "delete this", rendering the behaviour unpredictable, sooner or later it crashes. Just play around a bit .....
Can you try by chance the cvs version of urxvt? It is possibly fixed.
Can confirm, that this is fixed in CVS.
