Hide Forgot
Spec URL: http://technophobia.org/repo/SRPMS/gplcver.spec SRPM URL: http://technophobia.org/repo/SRPMS/gplcver-2.12a-12.fc23.src.rpm Description: Partial fix for existing broken package Fedora Account System Username: jrrk2 For attention of jcapik or chitlesh The existing gplcver package in FC23 is not 64-bit clean. This causes it to fail immediately. This patched version provides a partial fix by making the 32-bit build avoid calling stat/fstat and encountering the problem. It does nothing to address the problems of the 64-bit build. I appreciate the user base for this package is limited which is probably why it has not been noticed before. copr info for future use is dnf copr enable jrrk2/gplcver Applying for sponsorship as co-maintainer and/or for the package maintainer to adopt my changes.
Please describe in detail - the detailed, exact step-by-step procedure to reproduce the issue you are seeing - The exact issue you are seeing (if it segfaults, adding backtrace or so is also appreciated) - The expected behavior - How reproducible the issue is so that the current maintainers (or potential sponsors) can examine the issue or the patch you are trying to provide. Once changing the component to gplcver. Adding myself as CC in case that gplcver maintainers get nonresponsive.
Created attachment 1158007 [details] Verilog module which provokes the associated bug sudo yum install gplcver cver bugzilla_id_1336458.v Appears to be a memory corruption bug. *** Error in `cver': realloc(): invalid next size: 0x0000000001c6da50 *** ======= Backtrace: ========= /lib64/libc.so.6(+0x77d75)[0x7efbfe4d6d75] /lib64/libc.so.6(+0x82ad2)[0x7efbfe4e1ad2] /lib64/libc.so.6(realloc+0x184)[0x7efbfe4e2a34] cver(__my_realloc+0x12)[0x4dc9e2] cver[0x4dca75] cver(__get1_vtok+0x8fe)[0x4e8e2e] cver(__get_vtok+0x9d)[0x4e6cbd] cver(__rd_tskenable+0x92)[0x4373e2] cver[0x437c1b] cver(__rd_stmt+0x8d)[0x437d0d] cver(__rd_stmt+0x9aa)[0x43862a] cver[0x438868] cver[0x43898a] cver(__rd_stmt+0x1df)[0x437e5f] cver[0x430872] cver(__rd_moddef+0x25f)[0x4323af] cver(__rd_ver_src+0x40)[0x425080] cver(__dig_main+0x2363)[0x428003] /lib64/libc.so.6(__libc_start_main+0xf0)[0x7efbfe47f580] cver(_start+0x29)[0x421709] ======= Memory map: ======== 00400000-00587000 r-xp 00000000 fd:00 416487 /usr/bin/cver 00786000-0078a000 r--p 00186000 fd:00 416487 /usr/bin/cver 0078a000-0078f000 rw-p 0018a000 fd:00 416487 /usr/bin/cver 0078f000-00799000 rw-p 00000000 00:00 0 01c4a000-02919000 rw-p 00000000 00:00 0 [heap] 7efbf8000000-7efbf8021000 rw-p 00000000 00:00 0 7efbf8021000-7efbfc000000 ---p 00000000 00:00 0 7efbfe0ea000-7efbfe0ff000 r-xp 00000000 fd:03 2148360662 /home/Xilinx/Vivado/2016.1/lib/lnx64.o/libgcc_s.so.1 7efbfe0ff000-7efbfe2ff000 ---p 00015000 fd:03 2148360662 /home/Xilinx/Vivado/2016.1/lib/lnx64.o/libgcc_s.so.1 7efbfe2ff000-7efbfe300000 rw-p 00015000 fd:03 2148360662 /home/Xilinx/Vivado/2016.1/lib/lnx64.o/libgcc_s.so.1 7efbfe300000-7efbfe45f000 rw-p 00000000 00:00 0 7efbfe45f000-7efbfe616000 r-xp 00000000 fd:00 394385 /usr/lib64/libc-2.22.so 7efbfe616000-7efbfe816000 ---p 001b7000 fd:00 394385 /usr/lib64/libc-2.22.so 7efbfe816000-7efbfe81a000 r--p 001b7000 fd:00 394385 /usr/lib64/libc-2.22.so 7efbfe81a000-7efbfe81c000 rw-p 001bb000 fd:00 394385 /usr/lib64/libc-2.22.so 7efbfe81c000-7efbfe820000 rw-p 00000000 00:00 0 7efbfe820000-7efbfe823000 r-xp 00000000 fd:00 394391 /usr/lib64/libdl-2.22.so 7efbfe823000-7efbfea22000 ---p 00003000 fd:00 394391 /usr/lib64/libdl-2.22.so 7efbfea22000-7efbfea23000 r--p 00002000 fd:00 394391 /usr/lib64/libdl-2.22.so 7efbfea23000-7efbfea24000 rw-p 00003000 fd:00 394391 /usr/lib64/libdl-2.22.so 7efbfea24000-7efbfeb25000 r-xp 00000000 fd:00 394393 /usr/lib64/libm-2.22.so 7efbfeb25000-7efbfed24000 ---p 00101000 fd:00 394393 /usr/lib64/libm-2.22.so 7efbfed24000-7efbfed25000 r--p 00100000 fd:00 394393 /usr/lib64/libm-2.22.so 7efbfed25000-7efbfed26000 rw-p 00101000 fd:00 394393 /usr/lib64/libm-2.22.so 7efbfed26000-7efbfed47000 r-xp 00000000 fd:00 394378 /usr/lib64/ld-2.22.so 7efbfef29000-7efbfef2d000 rw-p 00000000 00:00 0 7efbfef41000-7efbfef46000 rw-p 00000000 00:00 0 7efbfef46000-7efbfef47000 r--p 00020000 fd:00 394378 /usr/lib64/ld-2.22.so 7efbfef47000-7efbfef48000 rw-p 00021000 fd:00 394378 /usr/lib64/ld-2.22.so 7efbfef48000-7efbfef49000 rw-p 00000000 00:00 0 7fff8cb7e000-7fff8cba2000 rw-p 00000000 00:00 0 [stack] 7fff8cbfa000-7fff8cbfc000 r--p 00000000 00:00 0 [vvar] 7fff8cbfc000-7fff8cbfe000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] Aborted (core dumped) desired behaviour (with my patch): /home/jrrk2/rpmbuild/BUILD/gplcver-2.12a.src/bin/cver bugzilla_id_1336458.v GPLCVER_2.12a of 05/16/07 (Linux-elf). Copyright (c) 1991-2007 Pragmatic C Software Corp. All Rights reserved. Licensed under the GNU General Public License (GPL). See the 'COPYING' file for details. NO WARRANTY provided. Today is Mon May 16 16:40:50 2016. Compiling source file "bugzilla_id_1336458.v" Highest level modules: tb glbl 00!! == 11 11!! == 11 22!! == 22 33!! == 66 44!! == 2244 55!! == 112200 testbench comparison failure 100000000000000100000100 $stop executed at time 10034080000 ps from source location **bugzilla_id_1336458.v(158). Type :help for help C1 > :q The correction only works if building for target i386. If building the existing package for i686, a different error occurs: [jrrk2@cerberus jrrk]$ cver bugzilla_id_1336458.v GPLCVER_2.12a of 05/16/07 (Linux-elf). Copyright (c) 1991-2007 Pragmatic C Software Corp. All Rights reserved. Licensed under the GNU General Public License (GPL). See the 'COPYING' file for details. NO WARRANTY provided. Today is Mon May 16 16:46:18 2016. **fatal err[1]: OS file stat operation failed: Value too large for defined data type [jrrk2@cerberus jrrk]$ The failure mode on 64-bit is similar with and without the patch.
Well, I don't think your patch will be accepted by the current maintainers unless you provide some explanation for your .fc23 patch. For example, I don't think the approach + if (!__quiet_msgs) { or + if (0) dmp_xpnd_olist(__opt_hdr); is the right way to fix the issue (and from the patch it is unclear how these change is related to the bug above).
Created attachment 1158196 [details] data file needed for readmem operation in Verilog testcase This file is needed for the simulation to work correctly. tar xzf mem.tgz prior to running the testcase
(In reply to Mamoru TASAKA from comment #3) > Well, I don't think your patch will be accepted by the current maintainers > unless you provide some explanation for your .fc23 patch. For example, I > don't think the approach > + if (!__quiet_msgs) { > or > + if (0) dmp_xpnd_olist(__opt_hdr); > is the right way to fix the issue (and from the patch it is unclear how > these change is related to the bug above). This is a fair point. I have not generated the minimal changes necessary to fix the bug. I simply generated diffs between the faulty version and a known good version. I take it your policy is one patch file per issue.
This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '23'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 23 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.