Created attachment 1899205 [details] list.txt Description of problem: Trying to build Ruby, the file crashes during creating of debuginfo [1]. The short reproducer with the attached list.txt is: ~~~ $ gdb --args file -N -f list.txt GNU gdb (GDB) Fedora 12.1-3.fc37 Copyright (C) 2022 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <https://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from file... Reading symbols from /usr/lib/debug/usr/bin/file-5.42-3.fc37.x86_64.debug... (gdb) r Starting program: /usr/bin/file -N -f list.txt This GDB supports auto-downloading debuginfo from the following URLs: https://debuginfod.fedoraproject.org/ Enable debuginfod for this session? (y or [n]) y Debuginfod has been enabled. To make this setting permanent, add 'set debuginfod enabled on' to .gdbinit. Downloading 0.01 MB separate debug info for system-supplied DSO at 0x7ffff7fc7000 Downloading 7.38 MB separate debug info for /lib64/libc.so.6 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Downloading 0.21 MB separate debug info for /lib64/libz.so.1 Program received signal SIGSEGV, Segmentation fault. 0x00007ffff7e6bf59 in __GI___mbrtowc (pwc=pwc@entry=0x7fffffffe12c L"啕", s=<optimized out>, s@entry=0x55555558b000 "/builddir/build/BUILDROOT/ruby-3.1.2-167.fc37.x86_64/usr/lib64/ruby/objspace.so", n=<optimized out>, n@entry=79, ps=ps@entry=0x7fffffffe130) at mbrtowc.c:85 Downloading 0.00 MB source file /usr/src/debug/glibc-2.35.9000-29.fc37.x86_64/wcsmbs/mbrtowc.c 85 status = DL_CALL_FCT (fct, (fcts->towc, &data, &inbuf, endbuf, (gdb) bt #0 0x00007ffff7e6bf59 in __GI___mbrtowc (pwc=pwc@entry=0x7fffffffe12c L"啕", s=<optimized out>, s@entry=0x55555558b000 "/builddir/build/BUILDROOT/ruby-3.1.2-167.fc37.x86_64/usr/lib64/ruby/objspace.so", n=<optimized out>, n@entry=79, ps=ps@entry=0x7fffffffe130) at mbrtowc.c:85 #1 0x00005555555574b9 in file_mbswidth (ms=ms@entry=0x55555555ca90, s=0x55555558b000 "/builddir/build/BUILDROOT/ruby-3.1.2-167.fc37.x86_64/usr/lib64/ruby/objspace.so") at /usr/src/debug/file-5.42-3.fc37.x86_64/src/file.c:606 #2 0x000055555555690c in unwrap (fn=<optimized out>, ms=0x55555555ca90) at /usr/src/debug/file-5.42-3.fc37.x86_64/src/file.c:534 #3 main (argc=4, argv=0x7fffffffe338) at /usr/src/debug/file-5.42-3.fc37.x86_64/src/file.c:275 (gdb) ~~~ Version-Release number of selected component (if applicable): $ rpm -q file file-5.42-3.fc37.x86_64 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: file crashes. Expected results: file does not crash. Additional info: [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=90003939
Just FTR, the last Rawhide build in Koschei did not suffer this issue: https://koschei.fedoraproject.org/build/13266483 Glibc might be the other possibility, because there seems to have been done some string related changes in 2.35.9000-30. Therefore I am adding Florian on CC.
And FTR, there are some upstream changes in the related code. Not sure if that changes anything: https://github.com/file/file/commit/c80065fe6900be5e794941e29b32440e9969b1c3
This makes almost everything FTBFS. Let's untag it?
I've opened https://pagure.io/releng/issue/10923
(In reply to Miro Hrončok from comment #3) > This makes almost everything FTBFS. Let's untag it? I have not tried older version of file myself, therefore I don't know it this is the right thing to do.
valgrind reports this for the reproducer: ==78== Invalid write of size 8 ==78== at 0x10A902: UnknownInlinedFun (file.c:533) ==78== by 0x10A902: main (file.c:275) ==78== Address 0x4aa2540 is 0 bytes after a block of size 800 free'd ==78== at 0x48476AF: realloc (vg_replace_malloc.c:1437) ==78== by 0x10A8EA: UnknownInlinedFun (file.c:529) ==78== by 0x10A8EA: main (file.c:275) ==78== Block was alloc'd at ==78== at 0x484286F: malloc (vg_replace_malloc.c:381) ==78== by 0x10A873: UnknownInlinedFun (file.c:510) ==78== by 0x10A873: main (file.c:275) Quoting from file.c in file-5.42-3.fc37: while ((len = getline(&line, &llen, f)) > 0) { if (line[len - 1] == '\n') line[len - 1] = '\0'; if (fi >= fimax) { fimax += 100; char **nf = realloc(flist, fimax * sizeof(*flist)); if (nf == NULL) goto out; } flist[fi++] = line; cwid = file_mbswidth(ms, line); if (cwid > wid) wid = cwid; line = NULL; llen = 0; } realloc invalidates flist; the assignment to nf is missing. So if fi >= fimax, things go quite wrong here. The reproducer has 126 lines, and fimax is 100, so this is all quite consistent. Introduced upstream by: https://github.com/file/file/commit/19bf47777d0002ee884467e45e6ace702e40a4c1 I don't see a fix yet. I'll try to patch this up.
Florian, do you build this in a side tag with the older file, or shall I do that?
Never mind me, I see now you tagged it it rawhide, and building in https://koji.fedoraproject.org/koji/taskinfo?taskID=90080517
Yeah, side tag didn't seem necessary because its own file list is short enough.
Thank you fweimer for solving this problem with lightning speed. I am sorry, I should have added a self-build test (https://src.fedoraproject.org/rpms/redhat-rpm-config/c/71f61e78a9061c908bae45d6d718cea7657761b7) and saved not only yours but everyone's time.
This bug appears to have been reported against 'rawhide' during the Fedora Linux 37 development cycle. Changing version to 37.
(In reply to Vincent Mihalkovič from comment #10) > Thank you fweimer for solving this problem with lightning speed. > > I am sorry, I should have added a self-build test > (https://src.fedoraproject.org/rpms/redhat-rpm-config/c/ > 71f61e78a9061c908bae45d6d718cea7657761b7) and saved not only yours but > everyone's time. The self-rebuild was fine. You'd have to test-build a couple larger packages. Martin Cermak maintains a scratch-build-based package rebuild test for toolchain packages, maybe we could reuse that for the file package as well.