[Serdev] Re: [Serusers] Re: adding a header

[Jiri Kuthan]

At 03:32 PM 7/8/2003, Mario Kolberg wrote:
>Andrei,
>
>thanks very much! I have now taken Jiri's advice and use the textops package to add the header.
>
>However, in the package, I'm calling append_hf with the message and a char* which is the new header. 

append_hf is to be supposed to be called with str* (casted to char *).


>From the look of it, it seems that append_hf should call str_fixup for the char*. 

str-fixup is only called during server boot.

-Jiri

ps -- I switched over this development discussion to the development list.

>This does not seem to happen. I included some debug messages and str_fixup is not called. Thus, the length of the string in append_hf_helper is just garbage. I have included an explicit call to str_fixup in append_hf and then everything works fine. I'm not sure how exactly the cmd_export_t structure is working - for append_hf it lists str_fixup.
>
>Thanks again for your help!
>
>Mario
>
>
>
>Andrei Pelinescu-Onciul wrote:
>>On Jul 07, 2003 at 16:30, Mario Kolberg <mko at cs.stir.ac.uk> wrote:
>>
>>>Andrei,
>>>
>>>thanks for the hint on the null-terminated headers! I removed the null termination and now I get a diffrent behaviour which depends on the length of the header added. I only manage a single register message. Either the ua (kphone) receives a reply or not - this depends on the length of the header. But in any case ser dies afterwards.
>>
>>There is a bug in the pscon module (this is yours isn't it?):
>>psconn.c line 138-139:
>>    nheader = pkg_malloc(strlen(test));$
>>    strcpy(nheader, test);$
>>You allocate strlen(test) but you copy in it strlen(test)+1 (strcpy
>>copies also \0, and strlen returns the lenght without \0).
>>This is caught by ser mem. debug code (ser by default is compiled with a
>>lot of debugging checks). ser malloc debug finds the end of a fragment
>>overriten, prints a BUG: message in the log and aborts() (to generate a
>>core).
>>This is how I found it:
>>grep " BUG:"  ser_crash_header
>>=> 5(3124) BUG: qm_*: prev. fragm. tail overwritten(c0c0c000, abcdefed)[0x80be7c8:0x80be7e0]!
>>It sais previous fragment, so I search for and address less than
>>0x80be7c8.
>>grep 0x80be ser_crash_header
>>=> several lines:
>>[...]
>> 5(3124)     162. N  address=0x80be630 frag=0x80be618 size=32
>> 5(3124)     163. N  address=0x80be680 frag=0x80be668 size=32
>> 5(3124)     164. N  address=0x80be6d0 frag=0x80be6b8 size=32
>> 5(3124)     165. N  address=0x80be720 frag=0x80be708 size=144
>>=> our offending fragment is 0x80be708
>>grep -A 2 0x80be708 ser_crash_header
>>=>
>> 5(3124)     165. N  address=0x80be720 frag=0x80be708 size=144
>> 5(3124)             alloc'd from pscon.c: exec_pol(138)
>> 5(3124)         start check=f0f0f0f0, end check= c0c0c000, abcdefed
>>(as you can see it overwrites one of the end check magic numbers with
>> one extra 0: c0c0c000 instead of c0c0c0c0).
>>BTW: that's what all those memory dumps in the logs are good for (and
>>for detecting memory leaks).
>>
>>Andrei
>
>-- 
>The University of Stirling is a university established in Scotland by
>charter at Stirling, FK9 4LA.  Privileged/Confidential Information may
>be contained in this message.  If you are not the addressee indicated
>in this message (or responsible for delivery of the message to such
>person), you may not disclose, copy or deliver this message to anyone
>and any action taken or omitted to be taken in reliance on it, is
>prohibited and may be unlawful.  In such case, you should destroy this
>message and kindly notify the sender by reply email.  Please advise
>immediately if you or your employer do not consent to Internet email
>for messages of this kind.  Opinions, conclusions and other
>information in this message that do not relate to the official
>business of the University of Stirling shall be understood as neither
>given nor endorsed by it.
>
>_______________________________________________
>Serusers mailing list
>serusers at lists.iptel.org
>http://lists.iptel.org/mailman/listinfo/serusers

--
Jiri Kuthan            http://iptel.org/~jiri/