xlock crashes. See the gdb backtraces in the following attaches. Reproducible: Always Steps to Reproduce: Just run xlock and when you are asked about password -- press enter twice.
Created attachment 135955 [details] (gdb) bt
Created attachment 135956 [details] (gdb) bt full
Created attachment 135957 [details] emerge --info
Can't reproduce at all; also the backtrace is not really that much useful. http://www.gentoo.org/proj/en/qa/backtraces.xml
I have read the link before the bug posting, and have included -ggdb in CFLAGS and splitdebug in FEATURES. That didn't create symbols for xlock itself however, but I don't think _they_ (xlock's symbols) are much useful. Which part of the backtrace is bad? If xlock's, I'll try to create symbols for it and repost here if succeed.
Why is this bug marked resolved? I can confirm the exact same behaviour. See below/attachments for emerge --info and the console output of xlock upon crashing if started from an xterm.
Created attachment 138447 [details] emerge --info
Created attachment 138451 [details] Output of xlock to console upon crashing
reopened
sys-fs/pam-0.99.9.0 x11-misc/xlockmore-5.25 Still a problem with current versions?
(In reply to comment #10) > sys-fs/pam-0.99.9.0 > x11-misc/xlockmore-5.25 > > Still a problem with current versions? Still the same behaviour with me.
I confirm this bug, with old and newer version. a small warkaround: export MALLOC_CHECK=0 before you run xlock
sorry, small typo correct code is: export MALLOC_CHECK_=0
I experienced this bug after merging pambase with the 'ssh' USE flag, but it works without the flag.
Try version 5.27: http://bugs.gentoo.org/show_bug.cgi?id=263317 Stopped crashing on UTF for me.
It's been couple of years now :-/ Please try xlockmore-5.29.1 (and reopen if required).