Bug 1336458

Summary:

Review Request: gplcver - interpreted Verilog simulator

Product:

[Fedora] Fedora

Reporter:

Dr Jonathan Kimmitt <jonathan>

Component:

gplcver

Assignee:

Jaromír Cápík <jaromir.capik>

Status:

CLOSED EOL

QA Contact:

Fedora Extras Quality Assurance <extras-qa>

Severity:

medium

Docs Contact:

Priority:

unspecified

Version:

CC:

chitlesh, jaromir.capik, jonathan, mtasaka

Target Milestone:

---

Target Release:

---

Hardware:

All

OS:

Linux

Whiteboard:

Fixed In Version:

Doc Type:

Bug Fix

Doc Text:

Story Points:

---

Clone Of:

Environment:

Last Closed:

2016-12-20 20:31:41 UTC

Type:

---

Regression:

---

Mount Type:

---

Documentation:

---

CRM:

Verified Versions:

Category:

---

oVirt Team:

---

RHEL 7.3 requirements from Atomic Host:

Cloudforms Team:

---

Target Upstream Version:

Embargoed:

Attachments:

Description	Flags
Verilog module which provokes the associated bug	none
data file needed for readmem operation in Verilog testcase	none

Description Dr Jonathan Kimmitt 2016-05-16 14:20:27 UTC

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.

Comment 1 Mamoru TASAKA 2016-05-16 14:54:36 UTC

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.

Comment 2 Dr Jonathan Kimmitt 2016-05-16 15:51:41 UTC

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.

Comment 3 Mamoru TASAKA 2016-05-17 07:05:00 UTC

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).

Comment 4 Dr Jonathan Kimmitt 2016-05-17 07:20:48 UTC

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

Comment 5 Dr Jonathan Kimmitt 2016-05-17 15:28:37 UTC

(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.

Comment 6 Fedora End Of Life 2016-11-25 09:03:27 UTC

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.

Comment 7 Fedora End Of Life 2016-12-20 20:31:41 UTC

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.