Summary:ASTERISK-13830: Crashes when executing a Stored Procedure against Sybase ASE 1.5.03
Reporter:Private Name (falves11)Labels:
Date Opened:2009-03-25 14:46:01Date Closed:2011-06-07 14:00:38
Versions:Frequency of
Environment:Attachments:( 0) 20090325__debug_bad_memory_without_valgrind.diff.txt
( 1) crash_sybase.txt
( 2) crash_sybase1.txt
Description:I can reproduce it 100% all the time.
I am uploading a GDB trace.
Comments:By: Private Name (falves11) 2009-03-25 14:59:29

I made a mistake, I was using trunk, not 1.6.1

By: Tilghman Lesher (tilghman) 2009-03-25 15:12:06

Please run this under valgrind, as documented in doc/valgrind.txt.

By: Tilghman Lesher (tilghman) 2009-04-03 15:40:59

Valgrind output is required to continue.

By: Private Name (falves11) 2009-04-03 16:01:50

It keeps crashing every few hours. I am using version SVN-branch-1.6.2-r186022 and it makes no difference. I am uploading the latest full backtrace. I cannot use valgrind in production. I guess this is a catch 22.

By: Tilghman Lesher (tilghman) 2009-04-03 16:27:47

Well, then, can you replicate the crash on a non-production system?

By: Tilghman Lesher (tilghman) 2009-04-03 16:34:02

You could also try this patch, which may find the memory corruption that normally could only be caught with valgrind.  To use, apply patch, then run 'make menuselect' and select MALLOC_HOLD from the compiler options.  This will output to the malloc debug file when an inappropriate memory access is made.

By: Private Name (falves11) 2009-04-03 18:58:43

The patch fails, but I think that it is a great idea. I am using 1.6.2 SVN.
19:55:51 (77.5 KB/s) - `-' saved [2541/2541]

patching file build_tools/cflags.xml
Hunk #1 succeeded at 16 with fuzz 2 (offset 7 lines).
patching file main/astmm.c
Hunk #1 succeeded at 47 (offset -3 lines).
Hunk #2 FAILED at 157.
Hunk #3 succeeded at 243 (offset 8 lines).
1 out of 3 hunks FAILED -- saving rejects to file main/astmm.c.rej

By: Tilghman Lesher (tilghman) 2009-04-04 11:13:15

Try using 1.6.1, which is the version you reported using in the original report.

By: Private Name (falves11) 2009-04-04 11:17:53

It is working well in production with 1.6.2. I will wait for a crash and the go back to 1.6.1. But think that we should have an option like that permanently, in all versions, because it is impossible for anybody to use valgrind in production, and the crashes do happen only under pressure, un production.

By: Private Name (falves11) 2009-04-08 12:03:16

Please close the case. I was forced to go back to version 1.4. The later versions do not handle codec. All versions after 1.4 have one way audio when the client offers two codecs. But 1.4 does not have the issue. I had to go back and use 1.4 trunk.

By: Tilghman Lesher (tilghman) 2009-04-08 16:33:17

Closed on request of reporter.