|
Bugzilla – Full Text Bug Listing |
| Summary: | "nano" crashes on search (^W Where is) | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 11.2 | Reporter: | Dimitar Pashov <d.pashov> |
| Component: | Basesystem | Assignee: | Petr Baudis <pbaudis> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Major | ||
| Priority: | P2 - High | CC: | agent.orange, andras.barna, anusko, bitdealer, forgotten_E-S6JZ1O-Q, georgmueller, knuckles, matz, pellice, pieter |
| Version: | Milestone 7 | ||
| Target Milestone: | --- | ||
| Hardware: | x86-64 | ||
| OS: | Other | ||
| Whiteboard: | . | ||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: |
screenshot of nano crashing
output of env gdb's bt full output gdb trace of nano crash |
||
in a few minutes/hours a "nano" package will appear here http://download.opensuse.org/repositories/editors/openSUSE_Factory/x86_64/ Please install it and tell me if you can still reproduce the problem. installed nano-2.1.11-5.1.x86_64 and it crashes in the same way for a regular user. There is a little difference in the way it crashes for root now. It finds the searched string and everything is fine I can even move the cursor left-right. As soon as I move the cursor up or down it crashes. (In reply to comment #2) > installed nano-2.1.11-5.1.x86_64 and it crashes in the same way for a regular > user. Ok, do this now: from the same repo install nano-debuginfo and nano-debugsource run as user gdb nano then do the task that crashes, you should return to a gdb) prompt, do enter "bt full" without quotes and upload the result here as an attachment.
> gdb nano
then in the gdb prompt enter "run".. then the rest...
Created attachment 320329 [details]
screenshot of nano crashing
I have reached to the point where nano crashes but the screen stays locked and I cannot get to gdb's prompt to get a trace. "ps aux | grep nano" shows: username 9177 0.3 0.2 35016 9980 pts/1 S 23:16 0:00 gdb nano username 9179 0.0 0.0 10300 1708 pts/1 S+ 23:16 0:00 /usr/bin/nano ctrl.l12 I tried to get to gdb's process with screen but couldn't. I run "kill -9 9179" then and I got to gdb's prompt but there was no stack trace because the process exitted on SIGKILL. open nano normallly then attach gdb to the process gdb --pid I cannot make it crash here, what is in your env ? specifically whats the value of MALLOC_CHECK_ and MALLOC_PERTURB_ env variables. ? I've done this and the output is attached. the env values are $MALLOC_CHECK_ : nothing $MALLOC_PERTURB_ : E The whole env is attached. There is another guy I know with factory and he can also reproduce it. Created attachment 320340 [details]
output of env
Created attachment 320341 [details]
gdb's bt full output
just checked with another guy nano crashes the same way. He has clean factory install (2-3 days) and no proprietary applications (i have the intel compiler). cannot reproduce yet. I've just got the live cd http://download.opensuse.org/factory/iso/openSUSE-KDE4-LiveCD-x86_64-Build0300-Media.iso to make sure it is not something local to my system. Booted it in vbox but the version installed there crashes in the same way. Installed the one from the "editors" repo but it still crashes. No crash running M8 i586, also valgrind does not report any issue. you are right indeed. It is fine on M8 i586 but does not work on M8 x86_64. I just installed both in separate vm's from the latest netinstall disks (30.09.2009). ok, arch-specific bug... I dont have an x86_64 factory installation atm, though. got it to crash. cool. hopefully it is the same crash Created attachment 329353 [details]
gdb trace of nano crash
I have the same problem with nano-2.1.99-13.1.x86_64
attached gdb trace
matz: can you take a look a this one, ? Im lost, looks like a GCC/Glibc problem. Up2date packages are here : http://download.opensuse.org/repositories/editors/openSUSE_11.2/ Same source and compiler options work without any crash in: a) openSUSE 11,2 i586 but crashes in x86_64 b) in any product older than 11.2, both 586 and x86_64, Hmpf. I can make it crash in STABLE too (glibc 2.10.1), on x86-64, but it doesn't crash or give any errors under valgrind. The crash itself is in: #0 malloc_consolidate (av=0x7f4eef370e60) at malloc.c:5111 #1 0x00007f4eef08f3d4 in _int_malloc (av=0x7f4eef370e60, bytes=1920) at malloc.c:4360 #2 0x00007f4eef091a79 in __libc_malloc (bytes=1920) at malloc.c:3660 I.e. glibc's internal malloc structures are barfed. Normally I would say that its probably some buffer overflow in nano, but as valgrind doesn't have to say anything interesting, this is hard to detect. MALLOC_CHECK_=1 or linking with -lmcheck just changes the point of segfault. I know the problem. It's a glibc bug in strncmp, which leads to a free
of a data structure that is accessed later (the search history, if anyone is
interested). This doesn't happen under valgrind because that has it's own
implementation of strncmp. To demonstrate the problem:
% cat bug.c
#include <string.h>
extern void abort (void);
static __attribute__((noinline)) mycmp (const char *a, const char *b)
{
return strncmp (a, b, (size_t)-1);
}
int main ()
{
if (mycmp ("", "bla") == 0)
abort ();
return 0;
}
% gcc bug.c
% ./a.out
Aborted
The problem is the very large size given to strncmp, this triggers a bug
in the AMD64 assembler implementation, which was always there. That's why
we removed strncmp.S after applying the patch since 2006. It seems this
part got lost. Petr, please look at e.g.
/work/SRC/old-versions/11.1/all/glibc/glibc.spec
(search for strncmp). Needs an update in 11.2 .
Thanks Michael, pulling hair for a while ;) Any idea when this issue will be repaired? Mainly as I use nano for a lot of 'searching' :) Thanks! (In reply to comment #24) > Any idea when this issue will be repaired? > > Mainly as I use nano for a lot of 'searching' :) > > Thanks! As this is a glibc bug, it may take some time to get fixed... stay tuned. (In reply to comment #25) > (In reply to comment #24) > > Any idea when this issue will be repaired? > > > > Mainly as I use nano for a lot of 'searching' :) > > > > Thanks! > > As this is a glibc bug, it may take some time to get fixed... stay tuned. Bummer! No worries, I'll use pico/vim for now :) Thanks! I'm sorry, I was holding off for some other stuff but I will just push out what I have at the start of next week. Petr, The updated nano package that was just pushed out today works perfectly. Thank you all again for your quick responses. -Matt Where can I find the update? It's not in the regular 11.2 update feed... Folks, again.. this is a glibc bug, nano source code may have changed and no longer trigger this bug though if this is the updated: http://download.opensuse.org/repositories/editors/openSUSE_11.2/x86_64/nano-2.2.0-10.2.x86_64.rpm i have to say, that this one still produces the segfault with the same behaviour (root segfaults instant wenn trying to search, user got 1 chance and segfaults after. i've tested it on 2 different machines, one virtual, one hardware, both x64 with most current (today) updates installed. Jan 5 18:09:02 test-hw kernel: [ 4067.654702] nano[2454]: segfault at 6372d29348 ip 00007fdca3473f8d sp 00007ffff0b3a0c0 error 4 in libc-2.10.1.so[7fdca3401000+151000] Jan 5 17:13:40 test-vm kernel: [448757.622448] nano[19326]: segfault at 6372d29348 ip 00007fec4df07f8d sp 00007fff45053080 error 4 in libc-2.10.1.so[7fec4de95000+151000] I can confirm this, my mistake! I just re-tested and saw the exact same issue. Worked once for user then crashed after that.. so my apologies for false hope. I'd like to add that we get the same problem on an Intel i7 64bit system under 11.2 with nano 2.2.0, so this is probably not just an AMD64 problem. I've just compiled and replaced the original 2.1.9 by the latest 2.2.2 and it REALLY seems solved. Can anyone else confirm please? I could only test it on my virtual machine, but yeah 2.2.2 works for me (as user and as root). 2.2.2 should be packed and put into the OSS repository. (In reply to comment #31) > if this is the updated: > http://download.opensuse.org/repositories/editors/openSUSE_11.2/x86_64/nano-2.2.0-10.2.x86_64.rpm > > i have to say, that this one still produces the segfault with the same > behaviour (root segfaults instant wenn trying to search, user got 1 chance and > segfaults after. > > i've tested it on 2 different machines, one virtual, one hardware, both x64 > with most current (today) updates installed. > > Jan 5 18:09:02 test-hw kernel: [ 4067.654702] nano[2454]: segfault at > 6372d29348 ip 00007fdca3473f8d sp 00007ffff0b3a0c0 error 4 in > libc-2.10.1.so[7fdca3401000+151000] > > Jan 5 17:13:40 test-vm kernel: [448757.622448] nano[19326]: segfault at > 6372d29348 ip 00007fec4df07f8d sp 00007fff45053080 error 4 in > libc-2.10.1.so[7fec4de95000+151000] Same thing here. I only have a x86-64 install to test, but this nano version gives me the first search result, then segfaults. Not fixed here. (In reply to comment #34) > I've just compiled and replaced the original 2.1.9 by the latest 2.2.2 and it > REALLY seems solved. Can anyone else confirm please? João is right, 2.2.2 solves it for me, and I've packaged it on my home project: http://download.opensuse.org/repositories/home:/knuckles/openSUSE_11.2/x86_64/nano-2.2.2-18.1.x86_64.rpm Please consider delivering the new nano 2.2.2 as an update to solve this issue. (In reply to comment #38) > ... > Please consider delivering the new nano 2.2.2 as an update to solve this issue. The x86_64/nano-2.2.2-18.1.x86_64.rpm fixed the problem here, too. This should be an update, post hast. nano 2.2.2 will appear in the next product, updating nano DOES NOT solve the real problem. Now this is ridiculous. This bug is about nano, which is the text editor of choice for many, many users. Now there seems to be a working RPM, and you're not pushing it out because it is "not the real bug"? It is one thing that glibc maintainers apparantly can't fix it any time soon, but refusing users an official update and leaving to to them to pick up an apparantly working nano, be it with a workaround or not, is outright counterproductive. Nothing's wrong with insisting on glibc getting the root fixed, but denying users a viable fix in the mean time is clearly wrong. Note that the maintenance update for glibc is already in the process of being approved. The SWAMPID for this issue is 30444. Please submit the patch and patchinfo file using this ID. (https://swamp.suse.de/webswamp/wf/30444) (In reply to comment #41) > but denying users a viable fix > in the mean time is clearly wrong. No, it is not a viable fix, nano is just one of the many packages that may be affected by this bug, and we are not going to fix them all, but release the right fix. what you suggest is a workaround, experience tells me that workarounds are a pain in the back to maintain in the long term. To all who can't live without it : You can install the 32bits version till the bug is fixed. Filed SR 30355 against the one in the "editors" repo which updates it to 2.2.2 and should fix this issue. Simply use that one if you want the x86_64 version once it got accepted. (URL: http://download.opensuse.org/repositories/editors/ ) Also please forward this to Factory since that contains still 2.1.9 for some reason. Submitted glibc update that should fix this issue, it should get released in couple of days; thank you for your patience. Update released for: glibc, glibc-debuginfo, glibc-debuginfo-32bit, glibc-debuginfo-x86, glibc-debugsource, glibc-devel, glibc-devel-debuginfo, glibc-html, glibc-i18ndata, glibc-info, glibc-locale, glibc-locale-debuginfo, glibc-obsolete, glibc-obsolete-debuginfo, glibc-profile, nscd, nscd-debuginfo Products: openSUSE 11.2 (debug, i586, i686, x86_64) |
User-Agent: Mozilla/5.0 (X11; U; Linux; en-GB) AppleWebKit/527+ (KHTML, like Gecko, Safari/419.3) rekonq The editor "nano" crashes with message: Search: Las*** glibc detected *** nano: malloc(): memory corruption (fast): 0x0000000000632ff0 *** when searches for some string ('Last' in the example above) in some text file. The crash happens if nano is launched from a regular user profile. If one swithes to root with su then searches for some string in a text file with nano. It finds the searched for string if available and gives Segmentation fault and returns to the command prompt when another button is pressed. The "Segmentation fault text" is enteren on the position of the cursor replacing whatever is next. If one swithes to root with su -l (or su -) nano works fine. No noticeable problems or crashes. Reproducible: Always Steps to Reproduce: 1. open some text file with nano from a regular user profile 2. press ctrl+w and enter some string to search for 3. press enter to execute the search Actual Results: Different dopending on the profile/environment. Described in the "Details" section. Expected Results: no crashes or segmentation faults are expected.