[syslog-ng] [Bug 253] Segfault when reloading configuration

[bugzilla at bugzilla.balabit.com]

https://bugzilla.balabit.com/show_bug.cgi?id=253





--- Comment #9 from Balazs Scheidler <bazsi at balabit.hu>  2013-10-14 14:32:26 ---
the funny thing about the backtrace, is that it is quite unlikely to happen. (althou' that's what memory corruptions usually are), but
anyway, the LogProtoServerOptions struct is filled single-threadedly right before the crash happens

The whole LogReaderOptions struct (where LogProtoServerOptions is embedded) is zero-initialized when the new configuration is loaded (when
allocating AFUnixSoureDriver instance, in afunix-source.c:222).

Once zero-initialized, log_reader_options_defaults() is called in afsocket-source.c:736, which in turn calls log_proto_server_options_defaults()
for the embedded struct. It sets a couple of fields to -1, but also sets the encoding field to NULL by the use of a wholesale memset as the first
routine in logproto-server.c:150

Once the config loaded encoding should be NULL, then syslog-ng commences initializing the new configuration, and calls 
log_reader_options_init() in afsocket-source.c:535, the role of this function is to inherit global options and to initialize derived fields
in the options structure, this happens quite close before the offending log_pipe_init() call that is the root for the crash.

The address of the just initialized struct is propagated to the kept-alive source connection using log_reader_set_options() in afsocket-source.c:146,
it uses self->owner to get the address of the LogReaderOptions struct, which is properly set by an earlier call to afsocket_sc_set_owner().

I'd really need a peek at the core files, to get some further clues, certainly it is possible that something frees the initialized struct under us, but at
this time syslog-ng is single-threaded (because of the config reload), it is doing its stuff during config initialization strictly sequentially and
the struct is initialized right before passed on to the crash-site.

The crash is btw related to /dev/log having outstanding connections when the reload happens, maybe you can trigger the crash a bit easier if you keep
a netcat hanging there on /dev/log

# keep this running during reload
$ nc -U /dev/log


-- 
Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.