[Serusers] Re: adding a header

[Mario Kolberg]

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. From the look of it, it seems that 
append_hf should call str_fixup for the char*. 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.