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@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
On Jul 08, 2003 at 14:32, Mario Kolberg mko@cs.stir.ac.uk 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. From the look of it, it seems that append_hf should call str_fixup for the char*.
append_hf is ment to be called from the script. When the script is processed str_fixup will be automatically called (and it will convert char* to str*). *_fixup functions area a way of pre-processing parameters on ser initialization (in this case instead of computing strlen(str) each time append_hf is called from the script, it will be computed only once on ser startup; another example is using it to compile the regular expressions only once , see search & fixup_regex).
If you call append_hf directly (not from the script) make sure it will receive str parameters. It expects str* parameters although is declared with char*.
E.g.: str str1; str1.s=your_string; str1.len=strlen(your_string); append_hf(msg, (char*) &str1, 0);
append_hf has char* parameters because this is the prototype for module exported function: typedef int (*cmd_function)(struct sip_msg*, char*, char*);
Andrei
-
Andrei Pelinescu-Onciul -
Mario Kolberg