Re: flexfax: Re: A clue: mailer died with signal 13

[Robert Colquhoun <rjc@trump.net.au>]

Hi Eloy,
Try altering:
 faxMailApp::~faxMailApp()
 {
     delete client;
     for (u_int i = 0, n = tmps.length(); i < n; i++)
         Sys::unlink(tmps[i]);
 }      

to

 faxMailApp::~faxMailApp()
 {
     if (client != NULL) delete client;
     for (u_int i = 0, n = tmps.length(); i < n; i++)
         Sys::unlink(tmps[i]);
 }      

see how that goes.

If it trys to delete a null pointer bad things usually happen.  If the
above doesn't fix it i'll have a go later with gdb.

Good Luck - Robert

At 13:05 8/04/98 +0000, Eloy A. Paris wrote:
>Hi again Robert,
>
>Robert Colquhoun <rjc@trump.net.au> wrote:
>
>: Firstly C++ 101:  new is like malloc but generates new objects in memory
>: rather than raw memory. delete is like free but deletes objects rather than
>: raw memory.
>:
>: Its a bit more complicated than that, but anyway.....
>
>OK, I got the idea :-)
>
>: The delete statement could cause a sigsegv in two ways, by freeing memory
>: it didnt own ie 'a' is NULL or something in the objects destructor which is
>: implicitly called.
>
>Nope, 'a' is not NULL (fprintf(stderr, "a=%p\n", a) gives something).
>
>: Looking at the faxMailApp destructor:
>: faxMailApp::~faxMailApp()
>: {
>:     delete client;
>:     for (u_int i = 0, n = tmps.length(); i < n; i++)
>:         Sys::unlink(tmps[i]);
>: }      
>: client is pointing to an object of type MySendFaxClient(hopefully it is
>: _not_ NULL)
>
>Well, if the -d flag is not used the client _is_ NULL. This might be a
>bug. However, client _is not_ NULL when -d is specified (I used
>fprintf's to be sore of this).
>
>I've just put a fprintf at the end of the faxMailApp destructor and
>execution is reaching that point.
>
>: MySendFaxClient::~MySendFaxClient() {}
>:
>: no sigsegv there!! , unlink might also do weird stuff if passed a bad
>: parameter.
>
>Right, "delete client" in ~faxMailApp() is not causing the
>segmentation fault.
>
>Also, I took a look at the parameters passed to Sys::unlink() and they
>are fine (strings for real files in /tmp).
>
>So, now I have a better understanding of C++ but I'm still clueless on
>why faxmail is crashing when calling the cleanup() function.
>
>Now I found out that if I comment out the call to "delete a" in
>cleanup(), the temporary files are left in /tmp. Obvious, isn't it?
>:-)
>
>: PS I might have missed something else obvious in the above but anyway
>: theres a start!!
>
>Probably a compiler or library problem?
>
>: PPS Is that rockwell the chip maker you work for?
>
>Kind of. Rockwell International has different bussinesses. Rockwell
>Telecommunications is the one that makes the faxmode chipsets. I'm in
>Rockwell Automation, the one that takes charge of automation and
>industrial control. We make PLC's (Logic Comtrollers, motors, motor
>controllers, pushbuttons, operator interface stuff, supervisory
>software, motor starters, relays, etc.)
>
>Regards,
>
>E.-
>
>-- 
>
>Eloy A. Paris
>Information Technology Department
>Rockwell Automation de Venezuela
>Telephone: +58-2-9432311 Fax: +58-2-9431645
>