http://www.kannel.org/pipermail/devel/attachments/20090826/42b1df45/attachment-0001.obj

On 27.09.2012, at 13:37, Rob GB <[email protected]> wrote:

> 
> Hi,
> 
> I think the fix was commited in this bug, but cannot find in the repo:
> 
> http://www.kannel.org/pipermail/devel/2009-August/002872.html
> 
> Could you guide me where the fix is?
> 
> Thanks.
> 
> ----------------------------------------
>> From: [email protected]
>> To: [email protected]
>> CC: [email protected]
>> Subject: RE: Kannel PANICS octstr_convert_range
>> Date: Thu, 27 Sep 2012 05:19:31 -0500
>> 
>> 
>> Hi Alex,
>> 
>> We would like to fix the v1.4.3 since v1.5.0 is not officially released.
>> 
>> I think we detected what type of MO is causing the problems, it is one with 
>> no data in the Data_sm message:
>> 
>> 
>> Flags: 0x18 (PSH, ACK)
>> 0... .... = Congestion Window Reduced (CWR): Not set
>> .0.. .... = ECN-Echo: Not set
>> ..0. .... = Urgent: Not set
>> ...1 .... = Acknowledgement: Set
>> .... 1... = Push: Set
>> .... .0.. = Reset: Not set
>> .... ..0. = Syn: Not set
>> .... ...0 = Fin: Not set
>> 
>> Window size: 32768
>> 
>> 
>> Short Message Peer to Peer, Command: Data_sm, Seq: 175, Len: 59
>> Length : 59
>> Operation : Data_sm (0x00000103)
>> Sequence #: 175
>> Service type: (Default)
>> Type of number (originator): International (0x01)
>> Numbering plan indicator (originator): ISDN (E163/E164) (0x01)
>> Originator address: 525534097529
>> Type of number (recipient): International (0x01)
>> Numbering plan indicator (recipient): ISDN (E163/E164) (0x01)
>> Recipient address: 5220302030000000
>> .... ..00 = Messaging mode: Default SMSC mode (0x00)
>> ..00 00.. = Message type : Default message type (0x00)
>> 00.. .... = GSM features : No specific features selected (0x00)
>> .... ..00 = Delivery receipt : No SMSC delivery receipt requested (0x00)
>> .... 00.. = Message type : No recipient SME acknowledgement requested (0x00)
>> ...0 .... = Intermediate notif: No intermediate notification requested (0x00)
>> 
>> 
>> Data coding: 0x00
>> SMPP Data Coding Scheme: SMSC default alphabet (0x00)
>> GSM SMS Data Coding
>> 0000 .... = DCS Coding Group for SMS: SMS DCS: General Data Coding 
>> indication - Uncompressed text, no message class (0x00)
>> ..0. .... = DCS Text compression: Uncompressed text
>> ...0 .... = DCS Class present: No message class
>> .... 00.. = DCS Character set: GSM 7-bit default alphabet (0x00)
>> GSM CBS Data Coding
>> 0000 .... = DCS Coding Group for CBS: CBS DCS: Language using the GSM 7-bit 
>> default alphabet (0x00)
>> ..00 0000 = DCS CBS Message language: German (0x00)
>> 
>> Optional parameters
>> Optional parameter: source_network_type (0x000e)
>> Tag: 0x000e
>> Length: 1
>> Originator network: GSM (0x01)
>> 
>> 
>> We think Kannel hits the assert != null error when it tries to parse the URL 
>> used for pushing the message to our server.
>> 
>> Do you know what patch we could apply to fix this problem?
>> 
>> Thanks indeed.
>> 
>> ///RGB
>> 
>> ----------------------------------------
>>> Subject: Re: Kannel PANICS octstr_convert_range
>>> From: [email protected]
>>> Date: Thu, 27 Sep 2012 10:30:25 +0200
>>> CC: [email protected]
>>> To: [email protected]
>>> 
>>> Hi Rob,
>>> 
>>> you are looking in the wrong direction. As far as I see from your crash 
>>> it's so that bearerbox send message to smsbox
>>> and not another way around. Therefore you have to check, what you still 
>>> have in the store file (if you delete it then also delete .bak files)
>>> and see in the access log of bearerbox which message cause crash.
>>> 
>>> Alex
>>> 
>>> P.S. I would suggest to upgrade to SVN version, it's more stable and 
>>> maintained as 1.4.3. 1.4.3 is very very old.
>>> 
>>> On 27.09.2012, at 10:06, Rob GB <[email protected]> wrote:
>>> 
>>>> 
>>>> Hi Alex,
>>>> 
>>>> I'm using Kannel 1.4.3, sorry for not mentioning this before.
>>>> 
>>>> Do you know by chance the context of where the error appeared in smsbox? I 
>>>> would like to understand the possible ways we can trigger the “assert != 
>>>> null” to fail.
>>>> 
>>>> Back-tracking from the error I find the following places the error could 
>>>> have come from:
>>>> 
>>>> ~/tmp/kannel$ find . -name "*.c" -exec grep -iH octstr_convert_range {} \;
>>>> 
>>>> ./gateway-1.4.3/gw/xml_shared.c: octstr_convert_range(charset, 0, 
>>>> octstr_len(charset), toupper);
>>>> ./gateway-1.4.3/gw/urltrans.c: octstr_convert_range(tmp, 0, 
>>>> octstr_len(tmp), tolower);
>>>> ./gateway-1.4.3/gw/urltrans.c: octstr_convert_range(os, 0, octstr_len(os), 
>>>> tolower);
>>>> ./gateway-1.4.3/gw/urltrans.c: octstr_convert_range(data, 0, 
>>>> octstr_len(data), tolower);
>>>> ./gateway-1.4.3/gw/wap_push_pap_compiler.c: octstr_convert_range(nameos, 
>>>> 0, octstr_len(nameos), tolower);
>>>> ./gateway-1.4.3/gw/wap_push_pap_compiler.c: octstr_convert_range(*address, 
>>>> 0, octstr_len(*address), tolower);
>>>> ./gateway-1.4.3/gw/wml_compiler.c: octstr_convert_range(escape, 0, 
>>>> octstr_len(escape), tolower);
>>>> ./gateway-1.4.3/gwlib/octstr.c:void octstr_convert_range(Octstr *ostr, 
>>>> long pos, long len,
>>>> ./gateway-1.4.3/gwlib/octstr.c: octstr_convert_range(ostr, 0, ostr->len, 
>>>> make_printable);
>>>> 
>>>> To me they all seem to point to an URL being bad or similar in a PAP 
>>>> request. However I have not changed anything in my config and underlaying 
>>>> APP for months.
>>>> 
>>>> I also wonder about the spool directory. Why does Kannel continue to crash 
>>>> unless we clean the spool directory?
>>>> 
>>>> Why are some messages left in the spool directory? The normal behaviour 
>>>> for in-/out-bound messages is for them to be stored in the spool directory 
>>>> and then deleted once they have been acknowledged to be received. So the 
>>>> question then becomes; What’s so “special” with the messages that remains 
>>>> in the spool directory?
>>>> 
>>>> Looking at the logs from today I find that we end keeping the message with 
>>>> ID d4e378df-8fa7-4d7b-83a3-bc28dfc44b12 in the spool directory and not the 
>>>> message with ID a45dd024-55dc-46f8-aefa-15d0bb321a73.
>>>> I cannot see any difference in the log file on why the first one is stored 
>>>> and the second isn’t.
>>>> 
>>>> 2012-09-27 08:14:49 [28185] [3] INFO: smsbox: Got HTTP request 
>>>> </cgi-bin/sendsms> from <10.223.205.193>
>>>> 2012-09-27 08:14:49 [28185] [3] INFO: sendsms used by <smsc1>
>>>> 2012-09-27 08:14:49 [28185] [3] INFO: sendsms sender:<smsc1:LabelSMS> 
>>>> (10.223.205.193) to:<522225257465> msg:<>
>>>> 2012-09-27 08:14:49 [28185] [3] DEBUG: Stored UUID 
>>>> d4e378df-8fa7-4d7b-83a3-bc28dfc44b12
>>>> 2012-09-27 08:14:49 [28185] [3] DEBUG: message length 0, sending 1 messages
>>>> 2012-09-27 08:14:49 [28185] [3] DEBUG: Status: 202 Answer: <Sent.>
>>>> 2012-09-27 08:14:49 [28185] [3] DEBUG: Delayed reply - wait for bearerbox
>>>> 2012-09-27 08:14:49 [28185] [0] DEBUG: Got ACK (0) of 
>>>> d4e378df-8fa7-4d7b-83a3-bc28dfc44b12
>>>> 2012-09-27 08:14:49 [28185] [0] DEBUG: HTTP: Resetting HTTPClient for 
>>>> `10.223.205.193'.
>>>> 
>>>> (...)
>>>> 
>>>> 2012-09-27 08:14:49 [28185] [3] INFO: smsbox: Got HTTP request 
>>>> </cgi-bin/sendsms> from <10.223.205.193>
>>>> 2012-09-27 08:14:49 [28185] [3] INFO: sendsms used by <smsc2>
>>>> 2012-09-27 08:14:49 [28185] [3] INFO: sendsms sender:<smsc2:LabelSMS> 
>>>> (10.223.205.193) to:<524423191572> msg:<>
>>>> 2012-09-27 08:14:49 [28185] [3] DEBUG: Stored UUID 
>>>> a45dd024-55dc-46f8-aefa-15d0bb321a73
>>>> 2012-09-27 08:14:49 [28185] [3] DEBUG: message length 0, sending 1 messages
>>>> 2012-09-27 08:14:49 [28185] [3] DEBUG: Status: 202 Answer: <Sent.>
>>>> 2012-09-27 08:14:49 [28185] [3] DEBUG: Delayed reply - wait for bearerbox
>>>> 2012-09-27 08:14:49 [28185] [0] DEBUG: Got ACK (0) of 
>>>> a45dd024-55dc-46f8-aefa-15d0bb321a73
>>>> 2012-09-27 08:14:49 [28185] [0] DEBUG: HTTP: Resetting HTTPClient for 
>>>> `10.223.205.193'.
>>>> 
>>>> 
>>>> Thanks a lot.
>>>> 
>>>> ///RGB
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> ----------------------------------------
>>>>> Subject: Re: Kannel PANICS octstr_convert_range
>>>>> From: [email protected]
>>>>> Date: Wed, 26 Sep 2012 18:58:32 +0200
>>>>> CC: [email protected]
>>>>> To: [email protected]
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> seems some queued message within bearerbox cause this panic. Try ether to 
>>>>> upgrade to the latest SVN version
>>>>> or delete bearerbox.store file.
>>>>> 
>>>>> Alex
>>>>> 
>>>>> On 26.09.2012, at 17:28, Rob GB <[email protected]> wrote:
>>>>> 
>>>>>> 
>>>>>> Hi Kannel people,
>>>>>> 
>>>>>> I have been using Kannel for almost 2 year, but today it has crashed and 
>>>>>> cannot make it work:
>>>>>> 
>>>>>> 
>>>>>> 2012-09-26 17:15:23 [28324] [0] INFO: Added logfile 
>>>>>> `/opt/kannel/log/smsbox.log' with level `1'.
>>>>>> 2012-09-26 17:15:23 [28324] [0] INFO: Logging accesses to 
>>>>>> '/opt/kannel/log/access.log'.
>>>>>> 2012-09-26 17:15:23 [28324] [0] INFO: Started access logfile 
>>>>>> `/opt/kannel/log/access.log'.
>>>>>> 2012-09-26 17:15:23 [28324] [0] INFO: HTTP: Opening server at port 13013.
>>>>>> 2012-09-26 17:15:23 [28324] [0] INFO: Set up send sms service at port 
>>>>>> 13013
>>>>>> 2012-09-26 17:15:23 [28324] [0] INFO: Connected to bearerbox at 
>>>>>> localhost port 13001.
>>>>>> 2012-09-26 14:59:38 [754] [4] PANIC: gwlib/octstr.c:2481: 
>>>>>> seems_valid_real: Assertion `ostr != NULL' failed. (Called from 
>>>>>> gwlib/octstr.c:836:octstr_convert_range.)
>>>>>> 2012-09-26 14:59:38 [754] [4] PANIC: 
>>>>>> /opt/kannel/sbin/smsbox(gw_panic+0x15b) [0x43c74b]
>>>>>> 2012-09-26 14:59:38 [754] [4] PANIC: /opt/kannel/sbin/smsbox [0x43cfc9]
>>>>>> 2012-09-26 14:59:38 [754] [4] PANIC: 
>>>>>> /opt/kannel/sbin/smsbox(octstr_convert_range+0x3d) [0x43d49d]
>>>>>> 2012-09-26 14:59:38 [754] [4] PANIC: 
>>>>>> /opt/kannel/sbin/smsbox(urltrans_find+0x55) [0x41cf75]
>>>>>> 2012-09-26 14:59:38 [754] [4] PANIC: /opt/kannel/sbin/smsbox [0x4156e0]
>>>>>> 2012-09-26 14:59:38 [754] [4] PANIC: /opt/kannel/sbin/smsbox [0x4337d5]
>>>>>> 2012-09-26 14:59:38 [754] [4] PANIC: /lib64/libpthread.so.0 
>>>>>> [0x372c20673d]
>>>>>> 2012-09-26 14:59:38 [754] [4] PANIC: /lib64/libc.so.6(clone+0x6d) 
>>>>>> [0x372b6d3d1d]
>>>>>> 
>>>>>> Neither Kannel nor our app nor the operating system have changed, Kannel 
>>>>>> just entered in PANIC and stopped working.
>>>>>> 
>>>>>> Kindly assist. Thanks.
>>>>>> 
>>>>>> ///RGB
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>                                         

Reply via email to