Multi-channel file descriptors - cause core dump (4.200)

[agrobman]

I was trying to write simultaneously to a file and sim log, but seems this does not work on 4.102 and causes core dump on 4.200.

% obj_dir/Vour
Hello World
Segmentation fault (core dumped)

the code is modified example from manual:

  module our;
  integer fd;

     initial begin 
        $display("Hello World"); 
        fd = $fopen("kuku.txt");
        fd = fd | 1;
        $fwrite(fd, "writing to kuku.txt\n");
        $fclose(fd);
        $finish; 
     end
  endmodule

with following CPP wrapper:

#include "Vour.h"
 #include "verilated.h"
 int main(int argc, char** argv, char** env) {
     VerilatedContext* contextp = new VerilatedContext;
     contextp->commandArgs(argc, argv);
     Vour* top = new Vour{contextp};
     while (!contextp->gotFinish()) { top->eval(); }
     delete top;
     delete contextp;
     return 0;
 }

It does write file if I comment out the line:

fd = fd | 1;

Change log shows that multichannel file descriptors were implemented back in 4.038 (?)
On 4.102 the "|1" seems just ignored - the $fwrite writes only to file, not to screen/log

what's wrong?

[wsnyder]

This should work, note t_display_mcd.v and t_sys_file_basic_mcd.v test this. Perhaps you could see what makes these different and provide a patch to fix whatever's up (likely a bug in verilated.cpp)?

[agrobman]

@wsnyder, I'm not C/C++ programmer you talk to me Chinese, I don't know ... I'm EE, know only verilog..

where should I see the mentioned files?

[agrobman]

Wilson, seems I miss something ..

the Verilog spec says that MCD should have bit 31 clear , t_display_mcd.v test uses 32'h8000_0001 and 32'h8000_0003 constants in $fwrite calls. (basicaly this test does no use MCD, but just checks predefined STDIN, STDOUT and STDERR predefined file descriptors)

the 2nd test just opens and closes files, but does not try to write to them to prove that the same data can be written to multiple files with single $fwrite statement and also there is no try to write to a file and STDOUT/log as my code tries to do...

[agrobman]

taking 1st complain about 2nd test back, I missed task 2, but there is no fd | 1 test - write to log and a file...

[agrobman]

update : writing to two files works:

module our;
 integer fd, fd1, all;

    initial begin 
       $display("%m:Hello World"); 
       fd = $fopen("kuku.txt");
       fd1 = $fopen("kuku1.txt");
       $display("fd=%h, fd1=%h",fd, fd1);
       all = fd | fd1;
       $fwrite(all, "writing to kuku.txt\n");
       $fclose(fd);
       $fclose(fd1);
       $finish; 
    end
 endmodule

[stephenry]

I did the MCD stuff last year. I'll take a look at it over the weekend. It's been a while but I can't recall if the MCD file descriptor treats bits 1/2 as STDOUT/STDERR. Perhaps it should, perhaps it shouldn't; will need to review the spec.

[agrobman]

update : segmentation fault was due my mistake : I used "ORed" descriptor in $fclose.

Now the code should be as

module our;
 integer fd, fd1, all;

    initial begin 
       $display("%m:Hello World"); 
       fd = $fopen("kuku.txt");
//        fd1 = $fopen("kuku1.txt");
       $display("fd=%h, fd1=%h",fd, fd1);
       all = fd | 1;
       $fwrite(all, "writing to kuku.txt\n");
       $fclose(fd);
//        $fclose(fd1);
       $finish; 
    end
 endmodule

log/results:

% obj_dir/Vour
our:Hello World
fd=40000000, fd1=00000000
- our.v:13: Verilog $finish

As you can see nothing was printed on screen, but kuku.txt is written:

% cat kuku.txt
writing to kuku.txt

[agrobman]

BTW, may be it's worth to check $fclose argument in simulator to avoid this segmentation fault ... - issue a runtime error or warning ...

[wsnyder]

$fclose is supposed to take a MCD, so I think your program was reasonable but there's probably a bug there, e.g. maybe it closes stdout? - @stephenry sounds like you offered to look when you get a chance - thanks!

[agrobman]

@stephenry , any updates for the issue? Do you confirm the problem?

[stephenry]

I did take a look at this over the weekend. Unfortunately, the only machine I have available to me at the moment is my M1. Verilator's regression environment does not appear to successfully link on this architecture yet and although I traced the issue down to the (recently updated) archival step in verilated.mk to produce the __ALL.a, I wasn't able to resolve the issue.

If I was to hazard a guess, the crash is caused by the fact that the "or 1" here, causes the 0'th entry in the MCD descriptor to become set (effectively bypassing the code for fopen which would create the file descriptor in that location). When attempting to write to this descriptor we end up dereferencing a null pointer. After initial inspection, I don't think I hardwired the 0th entry in the MCD descriptor to stdout.

I'll probably need to dig out my Linux box and fix it from there. Is this currently blocking you? Should be relatively easy to work around for the moment.

[agrobman]

I'm porting code from Xcelium to verilator. this is one of many problems on my way. Will be nice to get it fix sooner than later.
Remember fd | 1 does not work too!

[agrobman]

Any good news for me?

[agrobman]

Hi Wilson,

Does this fix my original problem - writing STDOUT and a file simultaneously ?

[wsnyder]

Yes.