Hi Bogdan.<br><br>Should I post it on the tracker, with the same detail of the last mail?<br><br>Regards.<br><br>Sergio<br><br><div class="gmail_quote">On Thu, Mar 6, 2008 at 5:14 AM, Bogdan-Andrei Iancu &lt;<a href="mailto:bogdan@voice-system.ro">bogdan@voice-system.ro</a>&gt; wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi Sergio,<br>
<br>
please upload your report on the tracker (bug section).<br>
<br>
Regards,<br>
Bogdan<br>
<br>
PS: please enable the memory debug support (DBG_QM_MALLOC) and run it<br>
like this - it might provide more infos when crashing.<br>
<div><div></div><div class="Wj3C7c"><br>
<br>
Sergio Gutierrez wrote:<br>
&gt; Hi Henning.<br>
&gt;<br>
&gt; I apologize in advance for the long post.<br>
&gt;<br>
&gt; These days, Openser still has been crashing randomly.<br>
&gt;<br>
&gt; Using GDB in one of the generated core files, I found something curious:<br>
&gt;<br>
&gt; #0 &nbsp;0x000bcfbc in fm_malloc (qm=0x185320, size=24, file=0xfedbac10<br>
&gt; &quot;res.c&quot;,<br>
&gt; &nbsp; &nbsp; func=0xfedbac70 &quot;db_mysql_get_columns&quot;, line=62) at mem/f_malloc.c:267<br>
&gt; #1 &nbsp;0xfedb74b0 in db_mysql_get_columns (_h=0x1cbf68, _r=0x24dde8) at<br>
&gt; res.c:62<br>
&gt; #2 &nbsp;0xfedb79f0 in db_mysql_convert_result (_h=0x1cbf68, _r=0x24dde8)<br>
&gt; at res.c:167<br>
&gt; #3 &nbsp;0xfedb28c4 in db_mysql_store_result (_h=0x1cbf68, _r=0xffbff830)<br>
&gt; at dbase.c:209<br>
&gt; #4 &nbsp;0xfedb40e8 in db_mysql_raw_query (_h=0x1cbf68,<br>
&gt; &nbsp; &nbsp; _s=0xff07e668 &quot;select received, contact, socket, cflags, path from<br>
&gt; location where expires &gt; &#39;2008-03-04 13:37:51&#39; and cflags &amp; 64 = 64<br>
&gt; and id % 1 = 0&quot;, _r=0xffbff830) at dbase.c:447<br>
&gt; #5 &nbsp;0xff053260 in get_all_db_ucontacts (buf=0x1ceec0, len=320054,<br>
&gt; flags=64, part_idx=0, part_max=1)<br>
&gt; &nbsp; &nbsp; at dlist.c:128<br>
&gt; #6 &nbsp;0xff0528c8 in get_all_ucontacts (buf=0x1ceec0, len=320058,<br>
&gt; flags=64, part_idx=0, part_max=1) at dlist.c:356<br>
&gt; #7 &nbsp;0xfee57c6c in pingClients (ticks=60, param=0x0) at functions.h:60<br>
&gt; #8 &nbsp;0x000aa430 in timer_ticker (timer_list=0x163c00) at timer.c:275<br>
&gt; #9 &nbsp;0x000aa180 in run_timer_process (tpl=0x1c5808, do_jiffies=1) at<br>
&gt; timer.c:357<br>
&gt; #10 0x000aa6fc in start_timer_processes () at timer.c:386<br>
&gt; #11 0x00036788 in main_loop () at main.c:873<br>
&gt; #12 0x0003a0c4 in main (argc=1137536, argv=0x155f1c) at main.c:1372<br>
&gt;<br>
&gt; By inspecting in detail the frame 0, in particular the qm variable:<br>
&gt;<br>
&gt; (gdb) print qm<br>
&gt; $1 = (struct fm_block *) 0x185320<br>
&gt;<br>
&gt;<br>
&gt; Which is the fm_block structure defined at mem/f_malloc.h.<br>
&gt;<br>
&gt; (gdb) frame 0<br>
&gt; #0 &nbsp;0x000bcfbc in fm_malloc (qm=0x185320, size=24, file=0xfedbac10<br>
&gt; &quot;res.c&quot;,<br>
&gt; &nbsp; &nbsp; func=0xfedbac70 &quot;db_mysql_get_columns&quot;, line=62) at mem/f_malloc.c:267<br>
&gt; 267 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; if ((*f)-&gt;size&gt;=size) goto found;<br>
&gt; (gdb) list<br>
&gt; 262 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; /*search for a suitable free frag*/<br>
&gt; 263<br>
&gt; 264 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; for(hash=GET_HASH(size);hash&lt;F_HASH_SIZE;hash++){<br>
&gt; 265 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; f=&amp;(qm-&gt;free_hash[hash].first);<br>
&gt; 266 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; for(;(*f); f=&amp;((*f)-&gt;u.nxt_free))<br>
&gt; 267 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; if ((*f)-&gt;size&gt;=size) goto found;<br>
&gt; 268 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; /* try in a bigger bucket */<br>
&gt; 269 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; }<br>
&gt; 270 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; /* not found, bad! */<br>
&gt; 271 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; return 0;<br>
&gt;<br>
&gt;<br>
&gt; If I print the qm-&gt;free_hash array, I found that is mainly empty; For<br>
&gt; the particular case of my core file, hash has a value of three, when<br>
&gt; printing that position I have the following:<br>
&gt;<br>
&gt; (gdb) print qm-&gt;free_hash[hash]<br>
&gt; $1 = {first = 0x69703a31, no = 1}<br>
&gt; (gdb) print qm-&gt;free_hash<br>
&gt; $2 = {{first = 0x0, no = 0}, {first = 0x0, no = 0}, {first = 0x0, no =<br>
&gt; 0}, {first = 0x69703a31, no = 1}, {<br>
&gt; &nbsp; &nbsp; first = 0x0, no = 0}, {first = 0x0, no = 0}, {first = 0x0, no =<br>
&gt; 0}, {first = 0x0, no = 0}, {first = 0x0,<br>
&gt; &nbsp; &nbsp; no = 0}, {first = 0x0, no = 0}, {first = 0x24dd68, no = 4641},<br>
&gt; {first = 0x0, no = 0} &lt;repeats 21 times&gt;, {<br>
&gt; &nbsp; &nbsp; first = 0x1ced90, no = 1}, {first = 0x0, no = 0} &lt;repeats 679<br>
&gt; times&gt;, {first = 0x1cef40, no = 1}, {<br>
&gt; &nbsp; &nbsp; first = 0x0, no = 0} &lt;repeats 1337 times&gt;, {first = 0x1cef40, no =<br>
&gt; 1}, {first = 0x0, no = 0}, {<br>
&gt; &nbsp; &nbsp; first = 0x24de38, no = 1}, {first = 0x0, no = 0} &lt;repeats 11<br>
&gt; times&gt;, {first = 0x21d100, no = 1}, {<br>
&gt; &nbsp; &nbsp; first = 0x0, no = 0}, {first = 0x0, no = 0}}<br>
&gt; (gdb) print qm-&gt;free_hash.no<br>
&gt; $3 = 0<br>
&gt; (gdb) print qm-&gt;free_hash[hash].first<br>
&gt; $4 = (struct fm_frag *) 0x69703a31<br>
&gt; (gdb) x/s 0x69703a31<br>
&gt; 0x69703a31: &nbsp; &nbsp; &nbsp;&lt;Address 0x69703a31 out of bounds&gt;<br>
&gt;<br>
&gt;<br>
&gt; So, the error happened because from the list of memory fragments, an<br>
&gt; invalid one was referred.<br>
&gt;<br>
&gt; I have two questions:<br>
&gt;<br>
&gt; 1. Is it normal that free_hash array at fm_block has some positions<br>
&gt; pointing to invalid locations?<br>
&gt; 2. I could see that the fm_frag_lnk struct has a member called no,<br>
&gt; which, for the printing, I see it is 0 for most of the values at the<br>
&gt; array, and it is 1 at some members, including the one which causes the<br>
&gt; crash; would it not be possible to use that member for a check before<br>
&gt; trying the allocation? What exactly means the no member, as I also see<br>
&gt; that for some of the members it has a value higher than 1.<br>
&gt;<br>
&gt; Thanks in advance for any help, and again, I apologize for the long post.<br>
&gt;<br>
&gt; Best regards.<br>
&gt;<br>
&gt; Sergio Gutierrez<br>
&gt;<br>
&gt;<br>
&gt; On Thu, Feb 28, 2008 at 11:49 AM, Sergio Gutierrez &lt;<a href="mailto:saguti@gmail.com">saguti@gmail.com</a><br>
</div></div><div class="Ih2E3d">&gt; &lt;mailto:<a href="mailto:saguti@gmail.com">saguti@gmail.com</a>&gt;&gt; wrote:<br>
&gt;<br>
&gt; &nbsp; &nbsp; Hi Henning.<br>
&gt;<br>
&gt; &nbsp; &nbsp; Thanks a lot for your answer.<br>
&gt;<br>
&gt; &nbsp; &nbsp; Currently, the machine does not report any hardware problem;<br>
&gt; &nbsp; &nbsp; Solaris 10 has a service called Fault Manager, which is running on<br>
&gt; &nbsp; &nbsp; my machine, and it has not reported any error or problem related<br>
&gt; &nbsp; &nbsp; to it.<br>
&gt;<br>
&gt; &nbsp; &nbsp; At this moment, I am testing a Openser installation compiled using<br>
&gt; &nbsp; &nbsp; an optimized version of GCC released by Sun to be used on Sparc<br>
&gt; &nbsp; &nbsp; Systems; this release is based on gcc 4, and at this time, OpenSER<br>
&gt; &nbsp; &nbsp; has been running for almost 18 hours without crash.<br>
&gt;<br>
&gt; &nbsp; &nbsp; I will inspect the core file again, and I will be posting what I find.<br>
&gt;<br>
&gt; &nbsp; &nbsp; Best regards, and thanks again.<br>
&gt;<br>
&gt; &nbsp; &nbsp; Sergio Gutierrez.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; &nbsp; &nbsp; On Thu, Feb 28, 2008 at 5:19 AM, Henning Westerholt<br>
</div>&gt; &nbsp; &nbsp; &lt;<a href="mailto:henning.westerholt@1und1.de">henning.westerholt@1und1.de</a> &lt;mailto:<a href="mailto:henning.westerholt@1und1.de">henning.westerholt@1und1.de</a>&gt;&gt;<br>
<div><div></div><div class="Wj3C7c">&gt; &nbsp; &nbsp; wrote:<br>
&gt;<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; On Thursday 28 February 2008, Sergio Gutierrez wrote:<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &gt; My OpenSER 1.3 installation running on Solaris Sparc is<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; facing random and<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &gt; unexpected crashes, in appearance related to timer process.<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &gt;<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &gt; The last core presents the following backtrace<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &gt;<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &gt; #0 &nbsp;0xfe977a04 in get_expired_dlgs (time=4233810208) at<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; dlg_timer.c:194<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &gt; #1 &nbsp;0xfe977540 in dlg_timer_routine (ticks=7980, attr=0x0) at<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &gt; dlg_timer.c:210<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &gt; #2 &nbsp;0x000a839c in timer_ticker (timer_list=0x15ec00) at<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; timer.c:275<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &gt; #3 &nbsp;0x000a80ec in run_timer_process (tpl=0x1b8088,<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; do_jiffies=1) at timer.c<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &gt;<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &gt; :357<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &gt;<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &gt; #4 &nbsp;0x000a8668 in start_timer_processes () at timer.c:386<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &gt; #5 &nbsp;0x00035ea8 in main_loop () at main.c:873<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &gt; #6 &nbsp;0x000397c4 in main (argc=-4195024, argv=0x150e9c) at<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; main.c:1372<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &gt;<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &gt;<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &gt; Thanks in advance for any hint you can give me.<br>
&gt;<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; Hi Sergio,<br>
&gt;<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; signal 10 is SIGBUS on solaris. This could be caused from an<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; invalid address<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; alignment, a segmention fault on a physical address and a<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; object hardware<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; error (wikipedia).<br>
&gt;<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; The first crashes were both caused from a get_all_ucontact,<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; triggered by a<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; timer. This crash is now another timer, deletion of expired<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; dialogs,<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; strange.. Is this machine otherwise stable, when (openser<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; release) does this<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; crashes started?<br>
&gt;<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; Do you have already inspected with the debugger the<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; datastructures in the code<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; of the get_expired_dlgs functions? Perhaps there is something<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; wrong in<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; there..<br>
&gt;<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; Cheers,<br>
&gt;<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; Henning<br>
&gt;<br>
&gt;<br>
&gt;<br>
</div></div>&gt; ------------------------------------------------------------------------<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; Users mailing list<br>
&gt; <a href="mailto:Users@lists.openser.org">Users@lists.openser.org</a><br>
&gt; <a href="http://lists.openser.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.openser.org/cgi-bin/mailman/listinfo/users</a><br>
&gt;<br>
<br>
</blockquote></div><br>