[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sr-dev
Subject:    [Serdev] Re: [Serusers] Re: adding a header
From:       Jiri Kuthan <jiri () iptel ! org>
Date:       2003-07-08 14:55:41
Message-ID: 5.2.0.9.0.20030708165355.033070e0 () localhost
[Download RAW message or body]

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@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@lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers

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


[prev in list] [next in list] [prev in thread] [next in thread]