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 > > >>> > > >>> > > >> > > > > > >
