log writer issue

Zeek
1

Hello List,

I am developing a Bro analyzer plugin and I have the following issue. The analyzer logs events into three different logfiles, one of which keeps crashing with this error:

Reporter::ERROR s7data/Log::WRITER_ASCII: terminating thread

This happens before the first event is logged, however the headers are already written into the logfile. I am fairly new to the Bro development so it might be some obvious mistake I make, but I could not find any solution on the internet.

I have attached the following files:

init_part.bro: the relevant part of the script, used for the logging

reporter.log: logfile that contains the error

s7data.log: the logfile that causes the crash

debug_s7data.log: relevant part of the debug.log file, when bro was run with -B threading switch

strace_4938: relevant part of the strace -f output

When creating the attached logs bro-2.4 was used, but I tested the analyzer with bro-2.4.1 as well and the problem persists.

I hope someone can point out the origin of the error and help me resolve this issue.

Thanks,

Gyorgy Miru

debug_s7data.log (328 Bytes)

init_part.bro (2.58 KB)

reporter.log (289 Bytes)

strace_4938 (3.16 KB)

debug_s7data.log (328 Bytes)

2

This happens before the first event is logged, however the headers are already written into the logfile

Was there a stderr.log ?

Does it happen before the event would have been logged at all, or in the process of logging the event?

If you add a

    print "This is siemenss7_write_data_unsigned"; #or siemenss7_read_data_unsigned
    print c$s7data;

before the calls to

    Log::write(S7comm::LOG3, c$s7data);

what gets output to stdout (or the stdout.log if you are using broctl)?

I think this may be caused by one of the fields in one of your events being invalid somehow...

debug_s7data.log: relevant part of the debug.log file, when bro was run with -B threading switch

You really want -B logging

I have a feeling you'll see a "Field type doesn't match in WriterBackend::Write" message

3

There was no stderr.log, however -B logging helped. It was in fact a type mismatch.

Thanks for the help,

Gy M