sinclude problem

[Stone <stones@iname.com>]

Dear all,

I have got into problem when I try to build the hylafax 4.0 patch level
1 on my BSDI machine:

1. When I finish configure and execute "make", there come up the error
messages:

"Makefile", line 42: Need an operator
"Makefile", line 67: Need an operator
"Makefile", line 383: Need an operator 

It seems that there are some syntax error in "Makefile". I have correct
the "include" to ".include" and quote the include file names.

2. When I try to execute "make" again, there comes another error:

"rules", line 197: Need an operator
Fatal errors encountered -- cannot continue

I found that line 197 is follow:
sinclude ${MKDEPFILE}  

Could someone tell me what's going wrong. Thank you!

Best regards,
Stone/<stones@iname.com>
                                       
Date: Mon, 28 Apr 1997 03:47:21 -0400 (EDT)
From: Robert Weiner <robert@progplus.com>
To: flexfax@sgi.com
Subject: Re: hfaxd(1M) dumps core for SNPP on SVR4
Sender: owner-flexfax@celestial.com


Reply to an old email so I included most of it below...

I finally found the time to upgrade my Hylafax to 4.0pl1 under SCO
OpenServer 3.2v4.2 and can confirm the "hfaxd crashing after page" problem
reported by Matthias.  GNU tools: gcc-2.7.0 and libg++-2.7.0a-1.  Modem:
Multitech 2834ZDX.

Did anyone find a fix yet?  (I didn't see a reply to this in the archives) 

I found that 'sendpage -q' (queued page, returns immediately) does not
trigger this bug where 'sendpage' (interactive wait for completion) does. 
Except for the syslog of "HylaFAX: CAUGHT SIGNAL 11" on the hfaxd child
process (which triggers the resulting sendpage error message), everything
else seems to work correctly with the page.

Here's the gdb-4.14 trace (I'm sorry if any line numbers are slightly off,
I was playing around inserting extra malloc/new and free/delete code
during my tests).  Basically, it does seem to always SEGV inside malloc. 

By inserting a 'malloc(128)' call before the 'new' line Matthias mentions
below, I found that it crashes in that malloc(128).  Note that inserting
'malloc(1)' didn't trigger a crash in malloc(1)... but it still crashed in
the 'new'.  I'd say that malloc's internal data structures got trashed
somewhere along the way. 

The gdb-4.14 trace:

Program received signal SIGSEGV, Segmentation fault.
0x6b5c0 in malloc ()
(gdb) where
#0  0x6b5c0 in malloc ()
#1  0x6bebc in __builtin_new (sz=44)
#2  0x1ccf in update__9FileCachePCcR4statUc (pathname=0x410290 "/doneq/q25", sb=0x7ffffa50,
    addToCache=1 '\001') at FileCache.c++:233
#3  0xb652 in findJobOnDisk__13HylaFAXServerPCcR5fxStr (this=0x410850, jid=0x40daa0 "25",
    emsg=0x7ffffb9c) at Jobs.c++:947
#4  0xbb22 in findJob__13HylaFAXServerPCcR5fxStr (this=0x410850, jobid=0x40daa0 "25",
    emsg=0x7ffffb9c) at Jobs.c++:1052
#5  0x260c7 in sendCmd__10SNPPServer (this=0x410850) at SNPPServer.c++:1284
#6  0x23c60 in cmd__10SNPPServer5Token (this=0x410850, t=T_SEND) at SNPPServer.c++:650
#7  0x233cf in parse__10SNPPServer (this=0x410850) at SNPPServer.c++:502
#8  0x730c in inputReady__13HylaFAXServeri (this=0x410850, fd=0) at HylaFAXServer.c++:413
#9  0x33089 in notify__10DispatcheriR6FdMaskN22 (this=0x40f528, nfound=1,
    rmaskret=0x7ffffcb8, wmaskret=0x7ffffca4, emaskret=0x7ffffc90) at Dispatcher.c++:664
#10 0x32cba in dispatch__10DispatcherP7timeval (this=0x40f528, howlong=0x0)
    at Dispatcher.c++:546
#11 0x32a67 in dispatch__10Dispatcher (this=0x40f528) at Dispatcher.c++:508
#12 0x284be in main (argc=7, argv=0x7ffffdc4, envp=0x7ffffde4) at main.c++:319
(gdb)

On Sun, 15 Sep 1996, Matthias Apitz wrote:

> From: Matthias Apitz <Matthias.Apitz@SOFTCON.de>
> Subject: hfaxd(1M) dumps core for SNPP on SVR4
> 
> The hfaxd(1M) child dumps core during SNPP-handling if the job
> is done.  At user-level in sendpage(1) this looks like:
> 
> $ sendpage -p 49171....... "hello world"
> destination pin 49171.......: request id is 32 for host localhost
> sendpage: Service not available, remote server closed connection
> sendpage:
> $
> 
> The page is sent anyway.
> 
> hfaxd(1M) awaits the message from faxq(1M) about the job done
> and then checks with stat(2) for "spool/sendq/q32" and for
> "spool/doneq/q32" (the job is moved to "spool/doneq/" by
> faxq(1M)). While allocating a new FileCache entry in hfaxd/FileCache.c++
> 
> FileCache::update( ... )
> 	...
>     /*
>      * Pathname not found in the cache.
>      */
>     if (Sys::stat(pathname, sb) < 0)
>         return (FALSE);
>     if (addToCache && pathname[0] != '.') {
>         if (fi) {
>             fi = oldest;
>             displaced++;
>         } else {
>             write(99, "newFileCache", strlen("newFileCache")); // DEBUG
>             fi = cache[h] = new FileCache;
>             write(99, "got?", strlen("got?"));                 // DEBUG
>         }
>         fi->name = pathname;
>         fi->serial = master++;
>         fi->sb = sb;
>     }
>     return (TRUE);
> 
> it dumps core. I've added two write(99,.....) statements to locate
> the place in the truss(1)-output of hfaxd(1M):
> 
>         poll(0x08045508, 2, -1)                         = 1
>         read(3, " S *\0", 2047)                         = 3
>         read(3, 0x08046D1C, 2047)                       = 0
>         poll(0x08045628, 2, -1)                         = 1
>         read(3, " !  02\0 :\004\0 cE1 ; 2".., 2047)     = 58
>         xstat(2, "/sendq/q32", 0x08046C58)              Err#2  ENOENT
>         read(3, 0x08046E3C, 2047)                       = 0
>         xstat(2, "/sendq/q32", 0x08047774)              Err#2  ENOENT
>         xstat(2, "/doneq/q32", 0x08047774)              = 0
>         write(99, " n e w F i l e C a c h e", 12)       Err#9  EBADF
>         ^^^^^^^^^^^^^^^^^^^^^^
>             Incurred fault #6, FLTBOUNDS  %pc = 0x0808EC0A
>               siginfo: SIGSEGV SEGV_ACCERR addr=0x00000004
>             Received signal #11, SIGSEGV [caught]
>               siginfo: SIGSEGV SEGV_ACCERR addr=0x00000004
> 
> As you can see from the truss(1) the 2nd write(99....) is not
> reached. I've no idea what should be wrong w/ the statement
> 	....
> 	fi = cache[h] = new FileCache;
> 	....
> 
> It's difficult for me to debug this 'cuze the gcc doesn't
> write debug information on SVR4. For me this looks like
> a "random writing to memory" at some other place.
> 
> Is someone also debuging this problem? Does this problem
> exist also on other systems?
> 
> 	matthias
> 

--
Robert Weiner / Programming Plus	Hardware & Software Consulting
Email: robert@progplus.com		Web: http://www.progplus.com