Hi, Sebastien.
Just want to inform, that it was entirely my fault.
I had wrong write to unallocated and uninitialized pointer, so memory
area was corrupted.
Best regards.
On 26.09.2011 15:00, Sebastien Decugis wrote:
> Is it possible that you mixed sources where DEBUG is defined zith
> sources where it is not?
>> Best regards,
> Sebastien.
>>> Le 2011/09/26 13:51, Vjacheslav Chekushin a écrit :
>> Thanks for reply.
>>>> I'm asking about it because of strange core dump in TRACE_DEBUG.
>>>> Here is backtrace for it:
>>>> Core was generated by `./freeDiameterd'.
>> Program terminated with signal 6, Aborted.
>> #0 0xb7700424 in __kernel_vsyscall ()
>> (gdb) bt
>> #0 0xb7700424 in __kernel_vsyscall ()
>> #1 0xb72fa951 in *__GI_raise (sig=6) at
>> ../nptl/sysdeps/unix/sysv/linux/raise.c:64
>> #2 0xb72fde42 in *__GI_abort () at abort.c:92
>> #3 0xb7331ded in __libc_message (do_abort=2, fmt=0xb73f90f8 "*** glibc
>> detected *** %s: %s: 0x%s ***\n")
>> at ../sysdeps/unix/sysv/linux/libc_fatal.c:189
>> #4 0xb733bff1 in malloc_printerr (action=<value optimized out>,
>> str=0x6 <Address 0x6 out of bounds>, ptr=0xb76fb000)
>> at malloc.c:6267
>> #5 0xb733d848 in _int_free (av=<value optimized out>, p=<value
>> optimized out>) at malloc.c:4795
>> #6 0xb734096d in *__GI___libc_free (mem=0xb76fb000) at malloc.c:3739
>> #7 0xb733a464 in _IO_free_backup_area (fp=0xb74154c0) at genops.c:214
>> #8 0xb733876d in _IO_new_file_overflow (f=0xb74154c0, ch=-1) at
>> fileops.c:863
>> #9 0xb7337988 in _IO_new_file_xsputn (f=0xb74154c0, data=0xb7664ff8,
>> n=8) at fileops.c:1358
>> #10 0xb730d235 in _IO_vfprintf_internal (s=0xb74154c0,
>> format=0xb7664ff8 "\t | tid:%-20s\t%s\tin %s@%s:%d\n\t%s|%*sPicked
>> next message\n",
>> ap=0xb2efb058 "\210\333\340\tG\261ļ²¯df\267\234\005f\267\v\004") at
>> vfprintf.c:1333
>> #11 0xb769c821 in fd_log_debug_fstr (fstr=0x0, format=0xb7664ff8 "\t |
>> tid:%-20s\t%s\tin %s@%s:%d\n\t%s|%*sPicked next message\n")
>> at /home/diameter/distr/freeDiameter_2231/libfdproto/log.c:67
>> #12 0xb75fc18b in process_thr (arg=0xb7677a28, action_cb=0xb75f60ad
>> <msg_rt_out>, queue=0x9df23d8,
>> action_name=0xb7665222 "Routing-OUT") at
>> /home/diameter/distr/freeDiameter_2231/libfdcore/routing_dispatch.c:1035
>> #13 0xb75fc8da in routing_out_thr (arg=0xb7677a28) at
>> /home/diameter/distr/freeDiameter_2231/libfdcore/routing_dispatch.c:1072
>> #14 0xb741e96c in start_thread (arg=0xb2efbb70) at pthread_create.c:300
>> #15 0xb739e56e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130
>>>> Do you have some thought about the possible reason?
>>>> On 26.09.2011 14:37, Sebastien Decugis wrote:
>>> Hi Vjacheslav,
>>>>>> As much as I recall it, this comment is mostly historical. In the early
>>> architecture of freeDiameter, the lock was provided by the daemon, in
>>> order to allow a different implementation to interleave with other
>>> traces. However the code was changed, the description was not updated at
>>> the same time... I will remove the misleading comments.
>>>>>> You can use the debug functions from an extension without any problem.
>>> If you want to use it from the main daemon, you have to initialize the
>>> freeDiameter library first.
>>>>>> Sorry for the confusion :)
>>>>>> Best regards,
>>> Sebastien.
>>>>>>>>>>>> Le 2011/09/26 10:29, Vjacheslav Chekushin a écrit :
>>>> Hi, Sebastien.
>>>>>>>> Could you explain what this comment means for fd_log_debug_fstr:
>>>>>>>> * This function assumes that a global mutex called "fd_log_lock" exists
>>>> * in the address space of the current process.
>>>>>>>>>>>> As I see log.c initializes this mutex by itself.
>>>>>>>> Do I need to do something in extension to use debugging facility?
>>>>>>>> Best regards,
>>>>>>> _______________________________________________
>>> Help mailing list
>>>Help at freediameter.net>>>http://lists.freediameter.net/cgi-bin/mailman/listinfo/help>>>>>>>>>>> _______________________________________________
> Help mailing list
>Help at freediameter.net>http://lists.freediameter.net/cgi-bin/mailman/listinfo/help
--
Vjacheslav Chekushin