|
Hylafax Mailing List Archives
|
[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
sinclude problem
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
