`char_backend_file` closes file handle in writefn, causing errors on subsequent writes

[donghyun-kang-dn]

Hi,

First of all, thanks for sharing this great project.

I am attempting to use char_backend_file as a UART module backend to log VP results efficiently. However, I encountered an issue where the logging fails after the first transaction.

Observation
It appears that char_backend_file::writefn closes the file handle (w_file) immediately after processing a transaction. This causes subsequent write attempts to fail because the file stream is no longer open.

Relevant Code
https://github.com/quic/qbox/blob/6531ba37fcec3ac1718c5a8bbe8455906db37675/systemc-components/backends/char_backend_file/include/char_backend_file.h#L115

// Current implementation
    void writefn(tlm::tlm_generic_payload& txn, sc_core::sc_time& t)
    {
        uint8_t* data = txn.get_data_ptr();
        for (int i = 0; i < txn.get_streaming_width(); i++) {
            size_t ret = fwrite(&data[i], sizeof(uint8_t), 1, w_file);
            if (ret != 1) {
                SCP_ERR(()) << "Error writing to the file.\n";
            }
        }
         fclose(w_file); // <--- This closes the file after every transaction
    }

Comparison
In contrast, the char_backend_stdio uses fflush(stdout) to handle the end of a transaction, keeping the stream open for continuous logging.

Proposed Fix
I believe the file should remain open during the simulation and only be closed upon destruction. I have tested the following modification, and it works as expected:

    void writefn(tlm::tlm_generic_payload& txn, sc_core::sc_time& t)
    {
        uint8_t* data = txn.get_data_ptr();
        for (int i = 0; i < txn.get_streaming_width(); i++) {
            size_t ret = fwrite(&data[i], sizeof(uint8_t), 1, w_file);
            if (ret != 1) {
                SCP_ERR(()) << "Error writing to the file.\n";
            }
        }
        fflush(w_file);  // Use fflush instead of fclose
    }

    // Add destructor to clean up file handles
    ~char_backend_file() 
    {
        if (w_file != nullptr) {
            fclose(w_file);
            w_file = nullptr;
        }
        if (r_file != nullptr) {
            fclose(r_file);
            r_file = nullptr;
        }
    }

Question
Is the current behavior (closing the file immediately) intended for a specific use case? If not, and this is indeed a bug, it would be great if this could be fixed in the upstream repo.

Thanks!

[markfoodyburton]

You may have noticed, we're not really using this backend very much, so it's good to have somebody kick it ;-)
I think "back in the day" there was a use case that wrote out one (large) message - for instance if you wanted to send a large chunk of text to a UART.

Maybe the "right" thing to do would be to detect if the last character is a ^d or so, and only then close the file?
Or, as you have it - close it on exit... I mean, I suppose we could have a cci param to say what to do....

[donghyun-kang-dn]

Thanks for the context!

I think the "close on exit" approach (using the destructor) also covers the historical use case as well. Even if a user sends only one large message, keeping the file open doesn't hurt—it will simply be closed slightly later when the simulation ends.

Since the current implementation causes an error for any additional messages, my proposal resolves the crash while maintaining compatibility with the "single message" scenario. So, I believe this simple fix would be sufficient without needing ^d detection or extra parameters.

[markfoodyburton]

Yeah - makes sense :-)
Could you write a patch (make sure to sign it :-) )

[donghyun-kang-dn]

I found that the existing test (file-backend-test) passed because all writes occurred in the same clock cycle. I've updated the test cases to simulate distinct transactions, confirmed the error, and verified the fix. Please see the PR for details. Thanks!

• On a side note, I noticed that recent qbox branches (like main) often reference libqemu tags that are not yet available in the public repository. Is this an unavoidable situation due to the internal release cycle? Just curious as it makes testing the latest version a bit tricky.