[Bug 600219] Re: faxgetty segfault
Giuseppe: I see your point. My hylafax server is running on a computer dedicated to that function. I am looking forward to upgrading to 12.04 LTS specifically because of this bug. Mark -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/600219 Title: faxgetty segfault To manage notifications about this bug go to: https://bugs.launchpad.net/hylafax/+bug/600219/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 600219] Re: faxgetty segfault
Any new developments with this bug? I have not (yet) installed the "enhanced logging" packages, as it seemed from Yaztromo's message that they may not be providing the required information. As before, I am running the non-optimized packages, and have not yet had another segfault. If it will help the effort, I could install the enhanced logging packages, which will presumably be more likely to segfault, and send along whatever logs they generate. Mark -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/600219 Title: faxgetty segfault To manage notifications about this bug go to: https://bugs.launchpad.net/hylafax/+bug/600219/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 600219] Re: faxgetty segfault
Yaztromo: I looks as though nobody has seen any segfaults with the completely un- optimized packages? I am coming up on a week of running un-optimized packages without any segfaults, though it took 8 days to catch one when I was running the "-O" packages. I will have to run unoptimized right up until I upgrade to 12.04 LTS in another month, before considering it error-free. Then, we can start all over again! Mark -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/600219 Title: faxgetty segfault To manage notifications about this bug go to: https://bugs.launchpad.net/hylafax/+bug/600219/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 600219] Re: faxgetty segfault
Perhaps it is not so easy gdb seems to exit as soon as a fax is received, even when it does not cause a segfault. Here is the log after it exits: toor@isabel:~$ cat /tmp/gdb-4945.log [New process 4951] [New process 5045] Program exited normally. No stack. /tmp/gdb-4945.batch:12: Error in sourced command file: No symbol table is loaded. Use the "file" command. toor@isabel:~$ Here is "dpkg -l", showing the packages properly installed: toor@isabel:~$ dpkg -l|grep hylafax|cut -c -80 ii hylafax-client 2:6.0.5-5 ii hylafax-server 2:6.0.5-5 ii hylafax-server-dbg 2:6.0.5-5 toor@isabel:~$ I will modify my "ps watcher" daemon to re-start gdb if needed after each fax comes in. Mark -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/600219 Title: faxgetty segfault To manage notifications about this bug go to: https://bugs.launchpad.net/hylafax/+bug/600219/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 600219] Re: faxgetty segfault
I have received a few more faxes with gdb running, but no segfaults so far. As before, gdb exits after each fax is received, and must be manually re-started. The log file for a normally received fax reads: root@isabel:/tmp# cat gdb-9245.log [New process 9251] [New process 9304] Program exited normally. No stack. /tmp/gdb-9245.batch:12: Error in sourced command file: No symbol "this" in current context. root@isabel:/tmp# "/usr/sbin/faxgetty" is still showing up as "stripped", despite installation of the "hylafax-server-dbg_6.0.5-5_i386.deb" package: root@isabel:/tmp# file /usr/sbin/faxgetty /usr/sbin/faxgetty: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, stripped root@isabel:/tmp# After gdb exits, there is a "/usr/sbin/faxgetty -D ttyS0" present in the process tree. Also, I fear that my system is hopelessly confused. I had previously installed hylafax 6.0.5 by compiling the source code. Before installing the "deb" packages you supplied, I ran a "make distclean", believing that it would delete all the previously installed files. That turned out not to be the case. Now, I have hylafax files in "/usr/local/sbin", from the previous install, as well as files in "/usr/sbin" from the more recent "deb" install. Also, my "/var/spool/hylafax/etc/config" file, which has the timestamp of the "deb" installation, still has multiple references to the old installation "/usr/local/sbin" ,"/usr/local/bin", and "/usr/local/lib" directories. In particular, "/usr/local/sbin/faxgetty" and "/usr/sbin/faxgetty" have different file sizes. I made sure that I specified "/usr/sbin/faxgetty" to be loaded by gdb-wrapper.sh. I suppose I could just clear the "/usr/local/sbin" directory, as the only files in it are from hylafax, then re-generate the config file so it specifies the "/usr/sbin" directory, and do the same for "/usr/local/bin" and "/usr/local/lib". Will it do any good to keep running "gdb" with a stripped faxgetty? Should I re-compile the source code with debugging info turned on? Can you supply a "deb" file with an unstripped faxgetty for Ubuntu 10.04? Should I wait for Ubuntu 12.04 LTS to become available in a few weeks, and see it that makes any difference? Thanks, Mark -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/600219 Title: faxgetty segfault To manage notifications about this bug go to: https://bugs.launchpad.net/hylafax/+bug/600219/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 600219] Re: faxgetty segfault
Late breaking news: I just had a series of segfaults, which has generated 2 ".core" files, each 878000 bytes long, each with a log file about 4500 bytes long. Here is one of the log files: root@isabel:/tmp# cat gdb-9574.log [New process 9580] Program received signal SIGSEGV, Segmentation fault. [Switching to process 9580] ModemServer::vtraceStatus (this=0x0, kind=1024, fmt=0xbfff50f0 "RECV/CQ: Adjusting for RTC found at row %u", ap=0xbfff5188 "z") at ModemServer.c++:950 950 ModemServer.c++: No such file or directory. in ModemServer.c++ Thread 2 (process 9580): #0 ModemServer::vtraceStatus (this=0x0, kind=1024, fmt=0xbfff50f0 "RECV/CQ: Adjusting for RTC found at row %u", ap=0xbfff5188 "z") at ModemServer.c++:950 #1 0x0807dca0 in FaxModem::copyQualityTrace (this=0x80ce268, fmt=0x80a6f24 "Adjusting for RTC found at row %u") at CopyQuality.c++:1198 #2 0x08080a24 in FaxModem::recvPageDLEData (this=0x80cde08, tif=0x80cf488, checkQuality=true, params=..., eresult=...) at CopyQuality.c++:309 #3 0x08070395 in Class1Modem::recvPageData (this=0x80cde08, tif=0x80cf488, eresult=...) at Class1Recv.c++:1859 #4 0x08070b55 in Class1Modem::recvPage (this=0x80cde08, tif=0x80cf488, ppm=@0xbfffe98c, eresult=..., id=...) at Class1Recv.c++:619 #5 0x080579e9 in FaxServer::recvFaxPhaseD (this=0x80c1d68, tif=0x80cf488, info=..., ppm=@0xbfffe98c, result=...) at FaxRecv.c++:247 #6 0x08058446 in FaxServer::recvDocuments (this=0x80c1d68, tif=0x80cf488, info=..., docs=..., result=...) at FaxRecv.c++:201 #7 0x08058bed in FaxServer::recvFax (this=0x80c1d68, callid=..., result=...) at FaxRecv.c++:69 #8 0x0805285c in faxGettyApp::processCall (this=0x80c1d68, ctype=2, eresult=..., callid=...) at faxGettyApp.c++:579 #9 0x080529cb in faxGettyApp::answerCall (this=0x80c1d68, atype=0, ctype=@0xb288, eresult=..., callid=..., dialnumber=0x0) at faxGettyApp.c++:542 #10 0x08054822 in faxGettyApp::answerPhone (this=0x80c1d68, atype=0, ctype=2, callid=..., dialnumber=0x0) at faxGettyApp.c++:429 #11 0x0805569d in faxGettyApp::listenForRing (this=0x80c1d68) at faxGettyApp.c++:248 #12 0x080559e3 in faxGettyApp::listenBegin (this=0x80c1d68) at faxGettyApp.c++:188 #13 0x08055a31 in faxGettyApp::inputReady (this=0xbfff50f0, fd=12) at faxGettyApp.c++:905 #14 0x0015ce51 in Dispatcher::notify(int, fd_set&, fd_set&, fd_set&) () from /usr/lib/hylafax/libhylafax-6.0.so.5 #15 0x0015ba8f in Dispatcher::dispatch(timeval*) () from /usr/lib/hylafax/libhylafax-6.0.so.5 #16 0x0015b9c9 in Dispatcher::dispatch() () from /usr/lib/hylafax/libhylafax-6.0.so.5 #17 0x08053c3d in main (argc=3, argv=0xb7e4) at faxGettyApp.c++:1150 #0 ModemServer::vtraceStatus (this=0x0, kind=1024, fmt=0xbfff50f0 "RECV/CQ: Adjusting for RTC found at row %u", ap=0xbfff5188 "z") at ModemServer.c++:950 #1 0x0807dca0 in FaxModem::copyQualityTrace (this=0x80ce268, fmt=0x80a6f24 "Adjusting for RTC found at row %u") at CopyQuality.c++:1198 #2 0x08080a24 in FaxModem::recvPageDLEData (this=0x80cde08, tif=0x80cf488, checkQuality=true, params=..., eresult=...) at CopyQuality.c++:309 #3 0x08070395 in Class1Modem::recvPageData (this=0x80cde08, tif=0x80cf488, eresult=...) at Class1Recv.c++:1859 #4 0x08070b55 in Class1Modem::recvPage (this=0x80cde08, tif=0x80cf488, ppm=@0xbfffe98c, eresult=..., id=...) at Class1Recv.c++:619 #5 0x080579e9 in FaxServer::recvFaxPhaseD (this=0x80c1d68, tif=0x80cf488, info=..., ppm=@0xbfffe98c, result=...) at FaxRecv.c++:247 #6 0x08058446 in FaxServer::recvDocuments (this=0x80c1d68, tif=0x80cf488, info=..., docs=..., result=...) at FaxRecv.c++:201 #7 0x08058bed in FaxServer::recvFax (this=0x80c1d68, callid=..., result=...) at FaxRecv.c++:69 #8 0x0805285c in faxGettyApp::processCall (this=0x80c1d68, ctype=2, eresult=..., callid=...) at faxGettyApp.c++:579 #9 0x080529cb in faxGettyApp::answerCall (this=0x80c1d68, atype=0, ctype=@0xb288, eresult=..., callid=..., dialnumber=0x0) at faxGettyApp.c++:542 #10 0x08054822 in faxGettyApp::answerPhone (this=0x80c1d68, atype=0, ctype=2, callid=..., dialnumber=0x0) at faxGettyApp.c++:429 #11 0x0805569d in faxGettyApp::listenForRing (this=0x80c1d68) at faxGettyApp.c++:248 #12 0x080559e3 in faxGettyApp::listenBegin (this=0x80c1d68) at faxGettyApp.c++:188 #13 0x08055a31 in faxGettyApp::inputReady (this=0xbfff50f0, fd=12) at faxGettyApp.c++:905 #14 0x0015ce51 in Dispatcher::notify(int, fd_set&, fd_set&, fd_set&) () from /usr/lib/hylafax/libhylafax-6.0.so.5 #15 0x0015ba8f in Dispatcher::dispatch(timeval*) () from /usr/lib/hylafax/libhylafax-6.0.so.5 #16 0x0015b9c9 in Dispatcher::dispatch() () from /usr/lib/hylafax/libhylafax-6.0.so.5 #17 0x08053c3d in main (argc=3, argv=0xb7e4) at faxGettyApp.c++:1150 $1 = (ModemServer * const) 0x0 Saved corefile /tmp/gdb-9574.core root@isabel:/tmp# I can email you the files if you like. This is good, eh? Mark -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. http
[Bug 600219] Re: faxgetty segfault
I installed the new packages yesterday. So far, no segfaults. Will keep watching and waiting -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/600219 Title: faxgetty segfault To manage notifications about this bug go to: https://bugs.launchpad.net/hylafax/+bug/600219/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 600219] Re: faxgetty segfault
I have reached one week since installing the "-O" packages. 77 faxes have been received during that time, with no segfaults. The OTHER problem I was having (the computer occasionally freezing until the mouse is moved) also seems to be fixed. I hope everything continues to work when I install Ubuntu 12.04 LTS next month! -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/600219 Title: faxgetty segfault To manage notifications about this bug go to: https://bugs.launchpad.net/hylafax/+bug/600219/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 600219] Re: faxgetty segfault
Simon:
I'm not a compiler expert, but it seems to me that "the offending code"
being executed is only a problem when some other process has previously
clobbered the "this" pointer. The offending code itself is probably
fine, but somewhere, perhaps in some data buffer management process
elsewhere, the address of the current "ModemServer" instance is getting
replaced by "0". Once that happens, any attempt to access a member of
ModemServer will cause a segfault. The problem isn't at line 950 (if
(log) { ), it's somewhere before that. Line 950 is just the first time
the program has a chance to fail because of the error.
Mark
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/600219
Title:
faxgetty segfault
To manage notifications about this bug go to:
https://bugs.launchpad.net/hylafax/+bug/600219/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 600219] Re: faxgetty segfault
I was just browsing the source code for ModemServer.c++, and I notice that ModemServer::vtraceStatus is called by ModemServer::traceStatus, which has, as one of its arguments, a variable length format string. It makes me wonder if the format string trailing NULL is what's clobbering the "this" pointer when it makes the call to vtraceStatus? Just a thought. Mark -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/600219 Title: faxgetty segfault To manage notifications about this bug go to: https://bugs.launchpad.net/hylafax/+bug/600219/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 600219] Re: faxgetty segfault
Simon: Good points. As I said earlier, back when I was having segfaults, these patterns emerged: 1) segfaults were very common when receiving from one particular sender, 2) when a segfault occurred from the problem sender, the sender would automatically try to send the fax again. It would often segfault again, but on a different page, 3) I have had segfaults occur during receipt of the first page, or during receipt of later pages in a multi-page fax. Note that I'm looking at a fairly small sample size: most of the segfaults I analyzed were on a single day. Being in a live office setting, if too many segfaults were occurring, my office staff would hook up the dedicated fax machine, and that was the end of data collection (as well as hylafax fax reception). If a dedicated fax machine, like the Minolta 2900, tries to re-send a fax that failed because the receiver (hylafax) crashed during the transfer, would it not send *exactly* the same data as the first time? That would make me think that it is not related to the actual data being sent, but definitely has something to do with the control signals. Is there any way to monitor the actual data transfer process, to see exactly what is going on just before a segfault? Mark -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/600219 Title: faxgetty segfault To manage notifications about this bug go to: https://bugs.launchpad.net/hylafax/+bug/600219/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 600219] Re: faxgetty segfault
yaztromo: Glad to hear your setup is working. I am now at 8 days of continuous running without a segfault, using the "-O" compiled packages. I wonder why the "-O" compiled packages didn't work for you? Hardware difference? (My fax server uses an AMD Athlon CPU). Anyway, I hope this is the end of this bug, and that it doesn't re-surface when Ubuntu 12.04 LTS comes out next month! Mark -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/600219 Title: faxgetty segfault To manage notifications about this bug go to: https://bugs.launchpad.net/hylafax/+bug/600219/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 600219] Re: faxgetty segfault
BAD NEWS!!! After going for 8 days without a problem, I just had 3 segfaults back- to-back! All occurred before the originating phone number was logged, so I can't tell if they were all from the same sender. The last fax received before the segfaults was from the sender that was causing problems before, but the most recent fax completed OK. I will, over the weekend, install the completely un-optimized packages, and see if they can run fault free. Mark -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/600219 Title: faxgetty segfault To manage notifications about this bug go to: https://bugs.launchpad.net/hylafax/+bug/600219/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 600219] Re: faxgetty segfault
I am trying to run a hylafax server in my office, and am getting tripped up by this same bug. My computer is running Desktop Ubuntu 10.04.4 LTS. I have tried 2 different serial modems with no difference noted. I compiled hylafax 6.05 from source, but this did not help. The segfault seems to occur when receiving a multi-page fax from one particular number. I have not confirmed this, yet. The resulting partial fax is in recvq, with abnormal permissions (600, instead of 644). The pages that are present are all correct; the error seems to be when switching to a new page. yaztromo (tromo)/Francesco (francesco-colista): You say that you "downgraded to the 8.04 version". Does that mean that you are using the ".deb" versions for 8.04 on a system running Ubuntu 10.04, or did you downgrade to Ubuntu 8.04? For now, I am setting up a cron file to check that faxgetty is running, and restarting it as needed, similar to the script that Hugo provided above. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/600219 Title: faxgetty segfault To manage notifications about this bug go to: https://bugs.launchpad.net/hylafax/+bug/600219/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 600219] Re: faxgetty segfault
Giuseppe: I will be happy to set up my system to generate debugging traces for you. I will also be paying close attention to when the error occurs. As I said, it seems that one particular sender seems to generate the error, but that could just be confirmation bias. After getting a segfault after 3 pages from the sender in question, I restarted faxgetty, and received several 12 page faxes in a row from another sender. As far as trying the latest packages, I can't do that right now. As I said, I am trying to get this working in a live environment, and every time the system crashes when I'm not around to fix it, my office staff just plugs in our old dedicated fax machine. Not good for data collection. Thanks for your interest. Mark -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/600219 Title: faxgetty segfault To manage notifications about this bug go to: https://bugs.launchpad.net/hylafax/+bug/600219/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 600219] Re: faxgetty segfault
Giuseppe: Some more info that may be helpful: I have reviewed my "/var/log/syslog" files, and have discovered that the faxgetty segfault only occurs when receiving a fax from one particular sender. Of the last 9 faxes received from that sender, 4 came thru OK, and 5 produced segfaults before being completed. When they re-send they fax that produced a segfault, the re-send can segfault on a different page. I spoke to the sender, and she told me that they have a lot of problems with that machine. It is a Konica/Minolta model 2900. The only other visible pattern concerns what I presume is the page size on the log entry. Every other sender produces a line in the log file of the form: ..RECV FAX (): from , page 1 in , INF, # line/mm, 2-D MMR, 14400 bit/s The offending sender has "A4" where the others have "INF". (I am in the USA, where A4 is not a commonly used page size). The offending sender also has "1-D MH" where *most* of the others have "2-D MMR". The 2 other incoming faxes that use "1-D MH" were single page. The logs cover a span of 5 days, during which 41 faxes were received, 6 of which ended prematurely with a segfault. (One segfault occurred while the first page was being received, so the log does not report what number it was originating from). Regarding the use of gdb: I have not used it before, but I'm willing to give it a shot. The messages you referred to, #15 and #21, are both links to a thread about segfaults occurring when a fax is being sent. So far, I have never had a segfault during a send, even to the machine that causes segfaults when we are receiving. Message #23 appears to have instructions for using gdb with faxgetty, but they are not very clear. Am I to understand that I should run: killall faxgetty; gdb- wrapper.sh faxgetty ttyS0? Thanks, Mark -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/600219 Title: faxgetty segfault To manage notifications about this bug go to: https://bugs.launchpad.net/hylafax/+bug/600219/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 600219] Re: faxgetty segfault
Giuseppe: Just to make sure I have this right: When I try to kill faxgetty, it immediately respawns. There is an entry in "/etc/init/" named "ttyS0.conf", which contains: start on stopped rc RUNLEVEL=[2345] stop on runlevel [!2345] respawn exec /usr/local/sbin/faxgetty ttyS0 I will change the last line to: exec gdb-wrapper.sh /usr/local/sbin/faxgetty ttyS0 That is correct? Mark -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/600219 Title: faxgetty segfault To manage notifications about this bug go to: https://bugs.launchpad.net/hylafax/+bug/600219/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 600219] Re: faxgetty segfault
Giuseppe: Problem: I renamed "/etc/init/ttyS0.conf" to prevent faxgetty from respawning, then re-booted. I ran gdb-wrapper.sh faxgetty ttyS0, but no faxgetty or gdb appeared in the list of processes. The logs in /tmp/gdb-1565.log say exactly this: /tmp/gdb-1565.batch:6: Error in sourced command file: Unrecognized or ambiguous flag word: "passhandle". I cannot find the string "passhandle" in the gdb-wrapper.sh script, /usr/bin/gdb, or in /usr/local/sbin/faxgetty. Ideas? Mark -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/600219 Title: faxgetty segfault To manage notifications about this bug go to: https://bugs.launchpad.net/hylafax/+bug/600219/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 600219] Re: faxgetty segfault
Giuseppe/Simon: I was not in my office yesterday, so I haven't yet tried the repaired "gdb-wrapper.sh" script. Looking at the log files, there were 2 segfaults: one was from a number different from the one that has been causing all of the segfaults to date, and the other occurred on the first page, before the number was logged. I did write a script to watch the process tree, and re-start faxgetty after it segfaults. Here it is: #!/bin/bash # monfaxgetty.sh - restart faxgetty daemon after segfault TGT=" faxgetty$" while true; do sleep 60 res=$(ps -A | grep "$TGT") if [ "$res" ]; then continue fi echo $(date) "-- faxgetty daemon not found. Restarting." /usr/local/sbin/faxgetty -D ttyS0 done This script is invoked by typing: nohup /var/spool/hylafax/bin/monfaxgetty.sh >> /var/log/monfaxgetty 2>&1 <&- & The redirection shenanigans at the end of the line redirects stderror to stdout (2>&1), and closes stdin (<&-) (you can also use 0<&-). Any time the daemon has to restart faxgetty, it logs the date and time to "/var/log/monfaxgetty". The script runs as a daemon, checking for faxgetty once a minute. The fact that my receptionist didn't plug the old fax machine back in yesterday after 2 segfaults indicates that it works as planned. If anyone reading this wants to use the script, pay very close attention to the spaces in the "res=" command. Bash is very fussy about spaces, and it took me several tries to get it right. Also, the definition of "TGT" is important: there is a single space, then "faxgetty$". I'll see if I can get the debugger running, and send the dumps from any further segfaults. Mark -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/600219 Title: faxgetty segfault To manage notifications about this bug go to: https://bugs.launchpad.net/hylafax/+bug/600219/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 600219] Re: faxgetty segfault
Giuseppe: I don't know if this is a problem or not. I killed "faxgetty", then executed "gdb-wrapper.sh /usr/local/sbin/faxgetty -D ttyS0". Faxgetty once again appears in the process tree, but the log at /tmp/gdb-24080.log reads: Program exited normally. No stack. /tmp/gdb-24080.batch:11: Error in sourced command file: No symbol table is loaded. Use the "file" command. The result of "file /usr/local/sbin/faxgetty" is: /usr/local/sbin/faxgetty: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, stripped As I said earlier, I had compiled hylafax 6.05 from source, but did not use any switches for including debugging symbols. gdb does not appear in the process tree, nor does any process with a pid of 24080. (faxgetty's pid is 24086) The result of "fuser /tmp/gdb-24080.log" is: /tmp/gdb-24080.log: 24086 The result of "lsof -p24086" is: COMMANDPID USER FD TYPE DEVICE SIZE/OFF NODE NAME faxgetty 24086 uucp cwdDIR8,3 4096 397885 /var/spool/hylafax faxgetty 24086 uucp rtdDIR8,3 4096 2 / faxgetty 24086 uucp txtREG8,3 477484 136322 /usr/local/sbin/faxgetty faxgetty 24086 uucp memREG8,3 113964 410036 /lib/ld-2.11.1.so faxgetty 24086 uucp memREG8,3 9748 410063 /lib/tls/i686/cmov/libutil-2.11.1.so faxgetty 24086 uucp memREG8,3 477612 136841 /usr/local/lib/libhylafax-6.0.so.5 faxgetty 24086 uucp memREG8,3 366580 145310 /usr/lib/libtiff.so.4.3.2 faxgetty 24086 uucp memREG8,379512 391113 /lib/libz.so.1.2.3.3 faxgetty 24086 uucp memREG8,3 975088 136780 /usr/lib/libstdc++.so.6.0.13 faxgetty 24086 uucp memREG8,3 149392 391032 /lib/tls/i686/cmov/libm-2.11.1.so faxgetty 24086 uucp memREG8,3 120368 390998 /lib/libgcc_s.so.1 faxgetty 24086 uucp memREG8,3 1405508 391024 /lib/tls/i686/cmov/libc-2.11.1.so faxgetty 24086 uucp memREG8,3 128616 136484 /usr/lib/libjpeg.so.62.0.0 faxgetty 24086 uucp memREG8,330496 391054 /lib/tls/i686/cmov/libnss_compat-2.11.1.so faxgetty 24086 uucp memREG8,379676 391042 /lib/tls/i686/cmov/libnsl-2.11.1.so faxgetty 24086 uucp memREG8,334408 391089 /lib/tls/i686/cmov/libnss_nis-2.11.1.so faxgetty 24086 uucp memREG8,342572 391076 /lib/tls/i686/cmov/libnss_files-2.11.1.so faxgetty 24086 uucp memREG8,3 256324 140902 /usr/lib/locale/en_US.utf8/LC_CTYPE faxgetty 24086 uucp memREG8,3 2454 207218 /usr/lib/locale/en_US.utf8/LC_TIME faxgetty 24086 uucp memREG8,326048 153218 /usr/lib/gconv/gconv-modules.cache faxgetty 24086 uucp0u CHR1,3 0t0791 /dev/null faxgetty 24086 uucp1u CHR1,3 0t0791 /dev/null faxgetty 24086 uucp2u CHR1,3 0t0791 /dev/null faxgetty 24086 uucp3r FIFO0,8 0t0 524621 pipe faxgetty 24086 uucp4w FIFO0,8 0t0 524621 pipe faxgetty 24086 uucp5r REG8,3 270 269268 /tmp/gdb-24080.batch (deleted) faxgetty 24086 uucp6w REG8,3 144 276646 /tmp/gdb-24080.log faxgetty 24086 uucp7w REG8,3 17 398290 /var/spool/hylafax/status/ttyS0 faxgetty 24086 uucp8u FIFO8,3 0t0 398300 /var/spool/hylafax/FIFO.ttyS0 faxgetty 24086 uucp9u CHR1,3 0t0791 /dev/null faxgetty 24086 uucp 10w FIFO8,3 0t0 398284 /var/spool/hylafax/FIFO faxgetty 24086 uucp 11u unix 0xe364e3c0 0t0 524633 socket faxgetty 24086 uucp 12u CHR 4,64 0t0969 /dev/ttyS0 >From this information, can you tell: is gdb "watching" faxgetty, ready to >produce useful information on the next segfault? Mark -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/600219 Title: faxgetty segfault To manage notifications about this bug go to: https://bugs.launchpad.net/hylafax/+bug/600219/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 600219] Re: faxgetty segfault
Giuseppe: > why don't you just make faxgetty start (and restart automatically) via > /etc/inittab? Infomation about this > configuration are in /usr/share/doc/hylafax-server/README.Debian.gz Recent versions of Ubuntu no longer use the "/etc/inittab" system. The current method is to have a file named "ttyS0.conf" in the directory "/etc/init/". The contents of "ttyS0.conf" are listed in message #53. With that file in place, if I perform a "killall faxgetty", faxgetty immediately re-spawns with a new PID. However, if faxgetty dies because of a segfault, it does not automatically respawn. Hence the need for a daemon to monitor the process tree. I couldn't think of a way to trigger a re-spawn whenever a segfault message was issued to "/var/log/syslog" , so I went with the polling method instead. Mark -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/600219 Title: faxgetty segfault To manage notifications about this bug go to: https://bugs.launchpad.net/hylafax/+bug/600219/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 600219] Re: faxgetty segfault
I am half way through our "busy day" at the office, using the "-O" hylafax-*_6.0.5-5_i386.deb packages (same md5sums as listed in message #84). So far today, we have received over 25 faxes, and no segfaults since the packages were installed last week. This is a longer time/more faxes without a segfault than I ever got with the original packages. W00t! -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/600219 Title: faxgetty segfault To manage notifications about this bug go to: https://bugs.launchpad.net/hylafax/+bug/600219/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
