188249 2007-08-09 18:01 0000 sys-apps/findutils-4.3.8: Segmentation fault (SIGSEGV) 2007-08-26 13:14:04 0000 1 1 1 Unclassified Gentoo Linux Applications 2007.0 All Linux RESOLVED FIXED P2 normal --- 1 Martin.vGagern@gmx.net base-system@gentoo.org truedfx@gentoo.org xake@rymdraket.net Martin.vGagern@gmx.net 2007-08-09 18:01:04 0000 I've got here a strange case of find dying on me with SIGSEGV after printing one line of output. I've located the following factors that seem to play a role: - LC_MESSAGES=C and LANG=de_DE.utf8 - Compiled with -O2 - --prefix=/usr so it can find installed files - find called with arguments -type f -ls - at least two files in current directory The problem does not occur if I set either LC_MESSAGES or LC_CTYPE to de_DE, or when I compile with -O0, or when I configure without arguments and don't install that build, or when I drop either argument to find. I've tryed to debug the issue. I traced the actual pagefault to an scenario where due to a wrong address a function pointer gets incremented instead of a simple integer counter. The address is four bytes off suggesting another off-by-one error, but I couldn't trace that. It's very difficult to trace the actual source of the error. Might possibly have security implications. Martin.vGagern@gmx.net 2007-08-09 18:01:51 0000 Created an attachment (id=127373) emerge --info Martin.vGagern@gmx.net 2007-08-09 19:31:54 0000 These might be steps to reproduce this issue: tar xf /usr/portage/distfiles/findutils-4.3.8.tar.gz cd findutils-4.3.8 ./configure --prefix=/usr CFLAGS="-O2 -g" make cd .. mkdir sandbox cd sandbox touch a b env -i LANG=de_DE.utf8 LC_MESSAGES=C ../findutils-4.3.8/find/find -type f -ls Please tell mewhether these steps work for you as well, at least if your arch and gcc is the same I'd expect they should, but I'm not sure. The expression will be parsed to a binary tree that looks like this in prefix notation: "-a" ( "-a" ( NULL, "-type f" ( NULL, NULL ) ), "-ls" ( NULL, NULL ) ) You can get this from "find -D tree -type f -ls". My primary breakpoint while debuggung this issue was apply_predicate. There you have a pointer p denoting the current predicate, and from its elements you can get the whole subtree. I found out that after prrinting ./a the expression "++(p->perf.successes);" in apply_predicate used a wrong address and instead of incrementing that counter incremented pred_ls which is the first element of struct predicate. The problem is that the pointer p used to address this counter is stored in ebx in apply_predicate, and somewhere in that register saving stuff I got lost. Next I tried the other direction, to find out in what way the factors described above influence the problem. I ltraced two calls and replaced all hexadecimal numbers (which includes all those addresses that change with each run) so they match. Diffing the result showed a difference in the setlocale result string, in one bsearch call which I don't understand yet and then the SIGSEGV itself caused by an fprintf(NULL, ...). So I guess it's going on somewhere in the library itself, perhaps somewhere where the results from localeconv are used. truedfx@gentoo.org 2007-08-09 19:52:42 0000 Could you please try editing lib/listfile.c and in the function list_file change modebuf's size from 11 to 12? strmode as provided by gnulib initialises elements 0 through 11, so a buffer of size 11 is insufficient. I'm not sure this is what's causing your specific problem though. truedfx@gentoo.org 2007-08-09 19:54:00 0000 Created an attachment (id=127395) findutils-4.3.8-overflow.patch Martin.vGagern@gmx.net 2007-08-09 20:07:41 0000 Works here as well. Did you find the impact of my environment, or was I just unlucky enough to hit this, and there is no real connection? How about this line "modebuf[10] = '\0';"? In the gnulib sources in that tarball that character will always be a space, corresponding to the space added by the fprintf in list file. So right now it doesn't make a difference. I'm not sure about the relation between findutils and gnulib, whether they will stay in touch and if not which one is more likely to introduce a + for files with ACLs. Should this issue be reported upstream as well? Will you do so? truedfx@gentoo.org 2007-08-09 20:27:16 0000 (In reply to comment #5) > Works here as well. I'm assuming you mean it still doesn't work :) > Did you find the impact of my environment, or was I just > unlucky enough to hit this, and there is no real connection? It's very likely that you were just unlucky enough to hit this. > How about this line "modebuf[10] = '\0';"? In the gnulib sources in that > tarball that character will always be a space, corresponding to the space added > by the fprintf in list file. So right now it doesn't make a difference. By calling strmode, an extra byte on the stack will be set to zero, which could with a specific compiler version and a specific optimisation level and specific versions of all used headers be an important byte. The problem is often enough something as simple as that, and as hard to trace as your own problem. > I'm not > sure about the relation between findutils and gnulib, whether they will stay in > touch and if not which one is more likely to introduce a + for files with ACLs. > > Should this issue be reported upstream as well? If it is a bug in findutils, then yes, but it's good to rule out a rare bug in the compiler and other parts of the environment first. > Will you do so? I'm not one of the maintainers of the Gentoo findutils package (I just have an interest in it); normally, for system packages, the issue will be reported upstream if/when the bug can be confirmed. Martin.vGagern@gmx.net 2007-08-09 20:39:02 0000 (In reply to comment #6) > I'm assuming you mean it still doesn't work :) ??? That patch works as it fixes my local build, and with that fix find works as it doesn't crash any more. So why would I mean it doesn't work? > If it is a bug in findutils, then yes, but it's good to rule out a rare bug in > the compiler and other parts of the environment first. I guess we can be pretty sure that's a bug in findutils. Once you've looked at it, it's pretty obvious that's going to break one day, and you only wonder why it didn't do so earlier. > I'm not one of the maintainers of the Gentoo findutils package (I just have an > interest in it); normally, for system packages, the issue will be reported > upstream if/when the bug can be confirmed. On the other hand, you found the solution (and pretty quick at that, considering how long I debugged that trying to write a better report. How did you do it?), so the honour of presenting that fix to the upstream devs should imho be yours. :-) truedfx@gentoo.org 2007-08-09 20:59:51 0000 I thought you were saying your findutils still segfaulted in the rest of your message, but I must have been misreading. I'm glad it's working. > How did you do it? I did little more than check how it ran when compiled with -fmudflap. @base-system: I'd really prefer it if one of you would contact upstream about this. vapier@gentoo.org 2007-08-25 15:19:23 0000 upstream has this fixed and ive merged that into 4.3.8-r1 vapier@gentoo.org 2007-08-26 13:14:04 0000 *** Bug 187241 has been marked as a duplicate of this bug. *** 127373 2007-08-09 18:01 0000 emerge --info emerge.info text/plain UG9ydGFnZSAyLjEuMy4zIChkZWZhdWx0LWxpbnV4L3g4Ni8yMDA3LjAvZGVza3RvcCwgZ2NjLTQu MS4yLCBnbGliYy0yLjYtcjAsIDIuNi4yMi1nZW50b28tcjIgaTY4NikKPT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KU3lzdGVt IHVuYW1lOiAyLjYuMjItZ2VudG9vLXIyIGk2ODYgSW50ZWwoUikgUGVudGl1bShSKSA0IENQVSAz LjAwR0h6CkdlbnRvbyBCYXNlIFN5c3RlbSByZWxlYXNlIDEuMTIuMTAKVGltZXN0YW1wIG9mIHRy ZWU6IFRodSwgMDkgQXVnIDIwMDcgMDg6NTA6MDEgKzAwMDAKZGlzdGNjIDIuMTguMyBpNjg2LXBj LWxpbnV4LWdudSAocHJvdG9jb2xzIDEgYW5kIDIpIChkZWZhdWx0IHBvcnQgMzYzMikgW2Rpc2Fi bGVkXQpkZXYtamF2YS9qYXZhLWNvbmZpZzogMS4zLjcsIDIuMC4zMy1yMQpkZXYtbGFuZy9weXRo b246ICAgICAyLjMuNi1yMiwgMi40LjQtcjQKZGV2LXB5dGhvbi9weWNyeXB0bzogMi4wLjEtcjYK c3lzLWFwcHMvc2FuZGJveDogICAgMS4yLjE4LjEKc3lzLWRldmVsL2F1dG9jb25mOiAgMi4xMywg Mi42MS1yMQpzeXMtZGV2ZWwvYXV0b21ha2U6ICAxLjRfcDYsIDEuNSwgMS42LjMsIDEuNy45LXIx LCAxLjguNS1yMywgMS45LjYtcjIsIDEuMTAKc3lzLWRldmVsL2JpbnV0aWxzOiAgMi4xNy1yMQpz eXMtZGV2ZWwvZ2NjLWNvbmZpZzogMS4zLjE2CnN5cy1kZXZlbC9saWJ0b29sOiAgIDEuNS4yNAp2 aXJ0dWFsL29zLWhlYWRlcnM6ICAyLjYuMjItcjIKQUNDRVBUX0tFWVdPUkRTPSJ4ODYgfng4NiIK QVVUT0NMRUFOPSJ5ZXMiCkNCVUlMRD0iaTY4Ni1wYy1saW51eC1nbnUiCkNGTEFHUz0iLW1hcmNo PXByZXNjb3R0IC1PMiIKQ0hPU1Q9Imk2ODYtcGMtbGludXgtZ251IgpDT05GSUdfUFJPVEVDVD0i L2V0YyAvdXNyL2tkZS8zLjUvZW52IC91c3Iva2RlLzMuNS9zaGFyZS9jb25maWcgL3Vzci9rZGUv My41L3NodXRkb3duIC91c3Ivc2hhcmUvWDExL3hrYiAvdXNyL3NoYXJlL2NvbmZpZyIKQ09ORklH X1BST1RFQ1RfTUFTSz0iL2V0Yy9lbnYuZCAvZXRjL2Vudi5kL2phdmEvIC9ldGMvZ2NvbmYgL2V0 Yy9waHAvYXBhY2hlMi1waHA1L2V4dC1hY3RpdmUvIC9ldGMvcGhwL2NnaS1waHA1L2V4dC1hY3Rp dmUvIC9ldGMvcGhwL2NsaS1waHA1L2V4dC1hY3RpdmUvIC9ldGMvcmV2ZGVwLXJlYnVpbGQgL2V0 Yy90ZXJtaW5mbyAvZXRjL3RleG1mL3dlYjJjIgpDWFhGTEFHUz0iLW1hcmNoPXByZXNjb3R0IC1P MiIKRElTVERJUj0iL3Vzci9wb3J0YWdlL2Rpc3RmaWxlcyIKRkVBVFVSRVM9ImNjYWNoZSBkaXN0 bG9ja3MgbWV0YWRhdGEtdHJhbnNmZXIgc2FuZGJveCBzZnBlcm1zIHN0cmljdCB1bm1lcmdlLW9y cGhhbnMgdXNlcmZldGNoIgpHRU5UT09fTUlSUk9SUz0iaHR0cDovL2dlbnRvby5pbmYuZWx0ZS5o dS8gaHR0cDovL2Z0cC1zdHVkLmZodC1lc3NsaW5nZW4uZGUvcHViL01pcnJvcnMvZ2VudG9vLyIK TEFORz0iZGVfREUudXRmOCIKTElOR1VBUz0iZW4gZGUiCk1BS0VPUFRTPSItajMiClBLR0RJUj0i L3Vzci9wb3J0YWdlL3BhY2thZ2VzIgpQT1JUQUdFX1JTWU5DX09QVFM9Ii0tcmVjdXJzaXZlIC0t bGlua3MgLS1zYWZlLWxpbmtzIC0tcGVybXMgLS10aW1lcyAtLWNvbXByZXNzIC0tZm9yY2UgLS13 aG9sZS1maWxlIC0tZGVsZXRlIC0tZGVsZXRlLWFmdGVyIC0tc3RhdHMgLS10aW1lb3V0PTE4MCAt LWV4Y2x1ZGU9L2Rpc3RmaWxlcyAtLWV4Y2x1ZGU9L2xvY2FsIC0tZXhjbHVkZT0vcGFja2FnZXMg LS1maWx0ZXI9SF8qKi9maWxlcy9kaWdlc3QtKiIKUE9SVEFHRV9UTVBESVI9Ii92YXIvdG1wIgpQ T1JURElSPSIvdXNyL3BvcnRhZ2UiClBPUlRESVJfT1ZFUkxBWT0iL3Vzci9sb2NhbC9wb3J0YWdl IC91c3IvcG9ydGFnZS9sb2NhbC9sYXltYW4vdm9pcCIKU1lOQz0icnN5bmM6Ly9yc3luYy5kZS5n ZW50b28ub3JnL2dlbnRvby1wb3J0YWdlIgpVU0U9IlggYWFjIGFjbCBhY3BpIGFkc2wgYWZtIGFs c2EgYXBhY2hlMiBhcnRzIGF1Y3RleCBhdWRpb2ZpbGUgYmFzaC1jb21wbGV0aW9uIGJjbWF0aCBi ZXJrZGIgYmlnZ2VyLWZvbnRzIGJpdG1hcC1mb250cyBiemlwMiBiemxpYiBjKysgY2Fpcm8gY2Rw YXJhbm9pYSBjZHIgY2hyb290IGNsaSBjcmFja2xpYiBjcnlwdCBjc3MgY3VwcyBjdXJsIGRiYSBk YnVzIGRoY3AgZGxsb2FkZXIgZG5kIGRvYyBkcmkgZHRzIGR2IGR2ZCBkdmRyIGR2ZHJlYWQgZWRz IGVtYWNzIGVtYm9zcyBlbmNvZGUgZXNjcmVlbiBlc2QgZXRoZXJlYWwgZXZvIGV4aWYgZmFhZCBm YW0gZmFzdGNnaSBmYmNvbiBmZm1wZWcgZmZ0dyBmaXJlZm94IGZsYWMgZmxhdGZpbGUgZm9ydHJh biBmdHAgZ2NjLWxpYmZmaSBnZCBnZGJtIGdpZiBnaW1wIGdpbXBwcmludCBnbnV0bHMgZ3BtIGdy YXBodml6IGdzIGdzdHJlYW1lciBndGsgaGFsIGhiY2kgaTh4MCBpY29udiBpZG4gaW1hZ2VtYWdp Y2sgaXB2NiBpc2RubG9nIGlzbzE0NzU1IGl0aHJlYWRzIGphYmJlciBqYXZhIGpwZWcga2RlIGtl cmJlcm9zIGxhZHNwYSBsYXRleCBsY21zIGxkYXAgbGVpbSBsZXNzdGlmIGxpcmMgbG1fc2Vuc29y cyBsb2dyb3RhdGUgbHpvIGx6dyBtYWQgbWFpbGRpciBtYWlsd3JhcHBlciBtaGFzaCBtaWRpIG1p a21vZCBtaW1lIG1qcGVnIG1teCBtbmcgbW90aWYgbW96eG1sdGVybSBtcDMgbXBlZyBtcGVnMiBt cGxheWVyIG1wbS13b3JrZXIgbXVkZmxhcCBtdWxlIG15c3FsIG5jdXJzZXMgbmV0IG5ldHdvcmsg bmxzIG5vLW9sZC1saW51eCBucHRsIG5wdGxvbmx5IG5zcGx1Z2luIG9kYmMgb2Z4IG9nZyBvcGVu Z2wgb3Blbm1wIG9wZXJhbm9tMiBvc3MgcGFtIHBjcmUgcGRmIHBlcmwgcGhwIHBpYyBwaWUgcGxv dHV0aWxzIHBuZyBwb3N0Z3JlcyBwb3ZyYXkgcHBwZCBwcm9jbWFpbCBweXRob24gcXQzIHF0M3N1 cHBvcnQgcXQ0IHF1aWNrdGltZSByZGVza3RvcCByZWFkbGluZSByZWFsIHJlY29kZSByZWZsZWN0 aW9uIHNhc2wgc2RsIHNlc3Npb24gc21pbWUgc25kZmlsZSBzb2NrZXRzIHNvY2tzNSBzb3ggc3Bl ZXggc3BlbGwgc3BsIHNzZSBzc2UyIHNzbCBzdmcgdGNsIHRjcGQgdGV0ZXggdGhyZWFkcyB0aHVu ZGVyYmlyZCB0aWZmIHRva2VuaXplciB0cmFuc2NvZGUgdHJhbnNsYXRvciB0cnVldHlwZSB0cnVl dHlwZS1mb250cyB0eXBlMSB0eXBlMS1mb250cyB1bmljb2RlIHVzYiB1c2VybG9jYWxlcyB1dGY4 IHY0bCB2NGwyIHZob3N0cyB2b3JiaXMgd2luMzJjb2RlY3Mgd21mIHg4NiB4YW5pbSB4Y2hhdHRl eHQgeGluZSB4bWwgeG9yZyB4c2NyZWVuc2F2ZXIgeHYgeHZpZCB4dm1jIHpsaWIiIEFMU0FfQ0FS RFM9ImFsaTU0NTEgYWxzNDAwMCBhdGlpeHAgYXRpaXhwLW1vZGVtIGJ0ODd4IGNhMDEwNiBjbWlw Y2kgZW11MTBrMSBlbXUxMGsxeCBlbnMxMzcwIGVuczEzNzEgZXMxOTM4IGVzMTk2OCBmbTgwMSBo ZGEtaW50ZWwgaW50ZWw4eDAgaW50ZWw4eDBtIG1hZXN0cm8zIHRyaWRlbnQgdXNiLWF1ZGlvIHZp YTgyeHggdmlhODJ4eC1tb2RlbSB5bWZwY2kiIEFMU0FfUENNX1BMVUdJTlM9ImFkcGNtIGFsYXcg YXN5bSBjb3B5IGRtaXggZHNoYXJlIGRzbm9vcCBlbXB0eSBleHRwbHVnIGZpbGUgaG9va3MgaWVj OTU4IGlvcGx1ZyBsYWRzcGEgbGZsb2F0IGxpbmVhciBtZXRlciBtdWxhdyBtdWx0aSBudWxsIHBs dWcgcmF0ZSByb3V0ZSBzaGFyZSBzaG0gc29mdHZvbCIgRUxJQkM9ImdsaWJjIiBGUklUWkNBUElf Q0FSRFM9ImZjcGNpIiBJTlBVVF9ERVZJQ0VTPSJldmRldiBqb3lzdGljayBrZXlib2FyZCBtb3Vz ZSB3YWNvbSIgS0VSTkVMPSJsaW51eCIgTENEX0RFVklDRVM9ImJheXJhZCBjZm9udHogY2ZvbnR6 NjMzIGdsayBoZDQ0NzgwIGxiMjE2IGxjZG0wMDEgbXR4b3JiIG5jdXJzZXMgdGV4dCIgTElOR1VB Uz0iZW4gZGUiIExJUkNfREVWSUNFUz0iaGF1cHBhdWdlIiBNSVNETl9DQVJEUz0iYXZtZnJpdHoi IFVTRVJMQU5EPSJHTlUiIFZJREVPX0NBUkRTPSJpODEwIGZiZGV2IHY0bCB2ZXNhIHZnYSIKVW5z ZXQ6ICBDVEFSR0VULCBFTUVSR0VfREVGQVVMVF9PUFRTLCBJTlNUQUxMX01BU0ssIExDX0FMTCwg TERGTEFHUywgUE9SVEFHRV9DT01QUkVTUywgUE9SVEFHRV9DT01QUkVTU19GTEFHUywgUE9SVEFH RV9SU1lOQ19FWFRSQV9PUFRTCgo= 127395 2007-08-09 19:54 0000 findutils-4.3.8-overflow.patch findutils-4.3.8-overflow.patch text/plain LS0tIGZpbmR1dGlscy00LjMuOC9saWIvbGlzdGZpbGUuYworKysgZmluZHV0aWxzLTQuMy44L2xp Yi9saXN0ZmlsZS5jCkBAIC0yMDAsNyArMjAwLDcgQEAKIAkgICBpbnQgbGl0ZXJhbF9jb250cm9s X2NoYXJzLAogCSAgIEZJTEUgKnN0cmVhbSkKIHsKLSAgY2hhciBtb2RlYnVmWzExXTsKKyAgY2hh ciBtb2RlYnVmWzEyXTsKICAgc3RydWN0IHRtIGNvbnN0ICp3aGVuX2xvY2FsOwogICBjaGFyIGNv bnN0ICp1c2VyX25hbWU7CiAgIGNoYXIgY29uc3QgKmdyb3VwX25hbWU7Cg==