RE: [BUG] EMI2 crashing.

2002-06-03 Thread Oded Arbel

Attached is a patch for octstr.c to make sure that even if null is submitted for an 
Octstr, nothing will break.
Applying it is really a philosophical question : does NULL is a valid Octstr* value ? 
the code is confusing about it : some functions choke when fed a NULL pointer, while 
others return with no error (w/o doing anything useful either, but that is to be 
expected when you're handed a NULL pointer).

--
Oded Arbel
m-Wise Inc.
[EMAIL PROTECTED]
(972)-67-340014
(972)-9-9581711 (ext: 116)

::..
You'l soon learn that there are no strange stars, no alien skies. Only skies and 
stars, in all their varieties. Each one with it's own flavor, and all flavors good
-- Xenocide / Orson Scott Card


 -Original Message-
 From: Oded Arbel 
 Sent: Sunday, June 02, 2002 6:39 PM
 To: Kannel-devel (E-mail)
 Subject: [BUG] EMI2 crashing.
 
 
 Hi list.
 
 Discovered two bugs relating to EMI2 module :
 
 1. emi2 is trying to create conn-name using octstr_format() 
 from the remote host, port and smsc-username, but for MO 
 connections username need not be defined, in which case NULL 
 is sent to octstr_format() as an Octstr* argument, on which 
 convert() is choking as it calls octstr_append() is a NULL 
 pointer, which of course panics. my solution was to hack 
 convert() to check 'new' after calling octstr_duplicate() on 
 the argument, and if it is null then to fake it as NULL. 
 I seem to recall that it once behaved in such a way - why 
 isn't it doing so now ?
 
 2. got a crash in emi2 with this log :
 2002-06-02 17:18:13 [11] DEBUG: EMI2[2022]: Got packet from 
 the main socket
 2002-06-02 17:18:13 [11] DEBUG: EMI2[2022]: emi2 parsing 
 packet: 00/00023/R/31/A//26
 2002-06-02 17:18:13 [11] DEBUG: EMI2[2022]: Got packet from 
 the main socket
 2002-06-02 17:18:13 [11] DEBUG: EMI2[2022]: emi2 parsing 
 packet: 01/00079/R/51/N/04/ Not accepted - Maximum messages 
 for the address exceeded/A6
 2002-06-02 17:18:13 [11] ERROR: EMI2[2022]: Got negative ack. 
 op:51, trn:1, error:4 (Operation not allowed), message: Not 
 accepted - Maximum messages for the address exceeded
 2002-06-02 17:18:13 [11] INFO: EMI2[2022]: SMSC is asking for 
 auth again, better reconnect
 2002-06-02 17:18:13 [11] DEBUG: EMI2[2022]: clear_sent called
 2002-06-02 17:18:13 [11] INFO: EMI2[2022]: connecting to Primary SMSC
 2002-06-02 17:18:13 [19] DEBUG: sms_router: time to sleep
 2002-06-02 17:18:13 [19] DEBUG: sms_router: list_len = 1
 2002-06-02 17:18:13 [19] DEBUG: sms_router: time to sleep
 2002-06-02 17:18:13 [19] DEBUG: sms_router: list_len = 1
 2002-06-02 17:18:13 [11] DEBUG: EMI2[2022]: emi2 sending 
 packet: 
 03/00105/O/51/962561555/2022///0108021718//3//6E7
 22E2032303230//0106050003000202///0A
 2002-06-02 17:18:13 [11] ERROR: Area 0xdeadbeef not found in 
 allocation table.
 2002-06-02 17:18:13 [11] PANIC: gwlib/octstr.c:2103: 
 seems_valid_real: Assertion `gw_check_is_allocated(ostr)' 
 failed. (Called from gw/smsc_emi2.c:872:emi2_do_send.)
 



octstr.patch
Description: octstr.patch


Re: [BUG] EMI2 crashing.

2002-06-03 Thread Aarno Syvänen

Oded Arbel kirjoittaa maanantaina, 3. kesäkuuta 2002, kello 
10:04:Attached is a patch for octstr.c to make sure that even if null is 
submitted for an Octstr, nothing will break.

 Applying it is really a philosophical question : does NULL is a valid 
 Octstr* value ? the code is confusing about it : some functions choke 
 when fed a NULL pointer, while others return with no error (w/o doing 
 anything useful either, but that is to be expected when you're handed a 
 NULL pointer).

Some modules use NULL Octstr for this variable has no value, and 
handle NULL using
this semantics. For others, it is plain error.  But I think they should 
handle NULL, too, for
robustness.

Aarno