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