Peter Eisenlohr <peter.eisenlohr@inform-software.com> writes:
Hi,
I also was able to reproduce the segfault. It always happened when a "mark" was generated. So, in order to reproduce this, set the mark intervall to a low value, i.e. mark(1).
I don't think it's a Problem of the 32bit NVTable patch, though. The following changes also made the segfault go away:
--- a/lib/driver.c +++ b/lib/driver.c @@ -158,7 +158,7 @@ log_src_driver_queue_method(LogPipe *s, LogMessage *msg, const LogPathOptions *p if (msg->flags & LF_LOCAL) afinter_postpone_mark(cfg->mark_freq);
- log_msg_set_value(msg, LM_V_SOURCE, self->super.group, self->group_len); + log_msg_set_value(msg, LM_V_SOURCE, self->super.group, strlen(self->super.group)); stats_counter_inc(self->super.processed_group_messages); stats_counter_inc(self->received_global_messages); log_pipe_forward_msg(s, msg, path_options);
It seems that self->group_len is not initialized correctly, resulting in some ridiculous large value_len being passed to nv_table_set value. I just found this, but did not have any further time to investigate. I suspect this has been there before the NVTable patch, but since the value_len exceeded the old NVTable max value size, nothing was inserted.
This sounds interesting! Thanks for the investigation, this will help me narrow down the issue tomorrow! -- |8]