Hello Oded!
>> hrer is the part of dlr.c (dlr_find_mem
function).
>> >> then typ=8 (message was delivered to smsc successful) we have typ & >> DLR_BUFFERED = 0 and dlr removed from list. but we are waiting for others >> deliverry report (by dlr_mask). may be here we have a problem? >If your waiting on SMSC_SUCCESS or SMSC_FAIL type delivery reports (which >shouldn't happen generally - you'r supposed to put the message in to dlr only >after you got SMSC_SUCCESS, and with SMSC_FAIL you don't put it in at all), >then calling DLR with one of those will remove the DLR record from storage. > >But thats all - no crash. ok. so, but then i'm wating for both DLR_SMSC_SUCCESS and DLR_SUCCESS dlrmask=9, then after receiving DLR_SMSC_SUCCESS executed code list_delete(dlr_waiting_list, i, 1); dlr_destroy(dlr); and may be it will be a problem in future (after DLR_SUCCESS received.) note about crash: i think crash occured in part of
smsc_emi2.c code in emi2_handle_smscreq function.
...
dlrmsg->sms.msgdata = octstr_duplicate(emimsg->fields[E50_AMSG]); octstr_hex_to_binary(dlrmsg->sms.msgdata); dlrmsg->sms.sms_type = report; ... looks like emimsg->fields[E50_AMSG] eq NULL
here.
I will try investigate it tomorow.
with br
German Aksenov
|
- kannel 1.2.1 crashes then dlr in use GAksenov
- Re: kannel 1.2.1 crashes then dlr in use Stipe Tolj
- kannel 1.2.1 crashes then dlr in use German Aksenov
- Re: kannel 1.2.1 crashes then dlr in use Oded Arbel
- RE: kannel 1.2.1 crashes then dlr in use German Aksenov
- RE: kannel 1.2.1 crashes then dlr in use Oded Arbel
- RE: kannel 1.2.1 crashes then dlr in use GAksenov
- RE: kannel 1.2.1 crashes then dlr in use GAksenov
- RE: kannel 1.2.1 crashes then dlr in use Oded Arbel
- RE: kannel 1.2.1 crashes then dlr in use Oded Arbel
- RE: kannel 1.2.1 crashes then dlr in use GAksenov
- RE: kannel 1.2.1 crashes then dlr in use Oded Arbel
- RE: kannel 1.2.1 crashes then dlr in use GAksenov
- RE: kannel 1.2.1 crashes then dlr in use GAksenov
- Re: kannel 1.2.1 crashes then dlr in use Stipe Tolj