Ya,
you are right. Thanks for dig into problem. Actually, in current
flatiron, corosync-objctl is fixed, so reread of mainconfig (and thus
logsys_format_set call) is not called after EVERY operation, so this
problem appear only after change of logging bits in objdb (thats why I
was not able to reproduce it). Nevertheless, problem is there, it's just
harder to reproduce it.
Can you send me your patch (if you have it)? You spent time to find real
issue and you deserver credit in coorosync changelog.
Regards,
Honza
jason napsal(a):
> Hi All,
>
> I think I have got the point. Corosync-blackbox can trigger calling
> log_format_set() two times, thus, format_buffer's value may becomes NULL
> temporary which cause log_printf_to_logs() access invalid memory address.
>
> After add logsys_config_mutex lock around format_buffer in
> log_printf_to_logs(), the segment fault never happens again.
> On Nov 28, 2012 11:12 AM, "jason" <huzhijiang@xxxxxxxxx> wrote:
>
>> Hi All,
>> By using corosync-1.4.4 and openais-1.1.4. We encountered a reproducable
>> segmentfalt. By exams with gdb we found it failed in log_printf_to_logs()
>> at liblogsys.so.4.0.0 at the following line:
>>
>> while ((c = format_buffer[format_buffer_idx])) {
>>
>> And the backtrace is:
>> log_printf_to_logs()
>> logsys_worker_thread()
>> start_thread()
>> clone()
>>
>> Only release version have this issue. If I turn --enable-debug when
>> compiling, then it will not happen.
>>
>> It can be reproduce by executing corosync-blackbox again and again quickly
>> and frequently while aisexec and its client application is running (to let
>> amf_dump_fn() really has something to print).
>>
>>
>
>
>
> _______________________________________________
> discuss mailing list
> discuss@xxxxxxxxxxxx
> http://lists.corosync.org/mailman/listinfo/discuss
_______________________________________________
discuss mailing list
discuss@xxxxxxxxxxxx
http://lists.corosync.org/mailman/listinfo/discuss
