Fix storing of lan log segfault

[airween]

There is a bug report in e-mail (via mailing list), where the reporter explained the situation: if he uses Tlf on two nodes then when he enter a QSO the receiver node exists with SEGFAULT.

The problem is that the function parse_qso() is called two times, and it uses the char *buffer variable directly. When the function is called first time, the used strtok_r() chain "eats" the buffer, and at the second call it uses an empty buffer.

Here are the traces:

• 1st call
  • background_process.c:165
  • log_to_disk.c:121
  • log_utils.c:87
• 2nd call
  • log_to_disk.c:123
  • addcall.c:233
  • log_utils.c:87

Both calls are necessary for a complete log, so I think the best solution is to copy the original buffer and operate with that.

[dl1jbe]

The fix would work but could be done better.

• Quick and simple way: Do the strdup() in log_to_disk() before calling parse_qso() and hand over the copy to parse_qso(), release it afterwards (need a change only in one place).

• Better way, but more work: First call to parse_qso() returns the parsed 'struct qso'. Use that in addcall2() like it is done for addcall() itself.

I suggest going the quick way just now. I will rework it afterwards into the second.

[airween]

The fix would work but could be done better.

* Quick and simple way: Do the strdup() in log_to_disk() before calling parse_qso() and hand over the copy to parse_qso(), release it afterwards (need a change only in one place).

but then addcall2() will call the parse_qso() again, and that will pass the lan_logline. Which won't be a problem anymore, but with this way it was enough to change only in one place too.

* Better way, but more work: First call to parse_qso() returns the parsed 'struct qso'. Use that in addcall2() like it is done for addcall() itself.

I thought it too but yes, it's more complex solution and I hadn't much time to review the whole code what will affect that modification.

I suggest going the quick way just now. I will rework it afterwards into the second.

So do you suggest to use your 1st solution?

[dl1jbe]

So do you suggest to use your 1st solution?

Yes please do. I will pick it up and make a reminder for myself to rework the addcall2 code into the second solution afterwards.

[zcsahok]

The fix does cure the segfault, just tested it.
The multi-logger setup is kind of usable for constant exchange contests. I guess the original focus must have been CQWW.
At least mid-term we have to consider supporting serial number distribution between the nodes.

Maybe it's my setup, but I don't see the node information recorded in the log. The 1st QSO was logged on Node B, the 2nd on Node A, but both appear to have originated from 0 (Node A).

 10CW  01-Oct-24 17:37 0001  AA1BB          599  599  05            K    05  0  
 10CW  01-Oct-24 17:41 0043  AA2CC          599  599  123                    0  28025.0

[airween]

The fix does cure the segfault, just tested it.

Indeed, that was the point.

The multi-logger setup is kind of usable for constant exchange contests. I guess the original focus must have been CQWW. At least mid-term we have to consider supporting serial number distribution between the nodes.

If the serial must be incremented, then - I think - it already works (apart from some very extreme cases).

Maybe it's my setup, but I don't see the node information recorded in the log. The 1st QSO was logged on Node B, the 2nd on Node A, but both appear to have originated from 0 (Node A).

 10CW  01-Oct-24 17:37 0001  AA1BB          599  599  05            K    05  0  
 10CW  01-Oct-24 17:41 0043  AA2CC          599  599  123                    0  28025.0

Let me check this too soon.

[zcsahok]

One more issue: upon restarting TLF complains about the log line length:
Some log lines are too short (maybe an old log format)!
Indeed, log lines from the net are just 80 characters long instead of 87. The frequency field seems to be missing.

[airween]

So do you suggest to use your 1st solution?

Yes please do. I will pick it up and make a reminder for myself to rework the addcall2 code into the second solution afterwards.

Done, see #443. Is this something you thought?

[dl1jbe]

Thanks. Just merged #443 in.

Already working on a change for addcall2() to accept a parsed struct qso_t instead of the logline.

[airween]

Thanks. Just merged #443 in.

Already working on a change for addcall2() to accept a parsed struct qso_t instead of the logline.

Thanks - I'm closing this PR.