----- Original message -----
On 11/17/2012 09:00 AM, Balazs Scheidler wrote:
dbparser: support inheriting properties in a corellation action
I merged this one, although I have some doubts. It uses log_msg_clone_cow(), which does have some tricky semantics, as it assumes that the cloned message will not change, once cloned.
I was thinking about removing clone_cow() completely because of this tricky stuff, and whenever we need a clone we're about to change the LogMessage anyway, and delaying the actual change means that we have to do two malloc() calls, instead of one.
Can you test whether changing the message that triggered the action with a rewrite rule, keeps the cloned one intact? This would need a parallel path to the db-parser(). It seems, that log_msg_clone_cow write protects the original log message, so trying to do a log_msg_set_value on the original message will result in an assertion. Sorry I didn't realize this when doing the original patch, explicitly copying all the name-value pairs seemed inefficient, but this behaviour is not desirable. Should I rework the patch this way or is there a better way of doing it?
I'd drop clone_cow() now, and implement a proper clone that allocates the logmsg header and nvtable in a single block, and copies everything through. that way clone+change becomes cheaper and you got a clone call that works in this case too.