BackupPC-users

Re: [BackupPC-users] BackupPC_dump stalls and leave zombie process

2009-08-23 22:21:14
Subject: Re: [BackupPC-users] BackupPC_dump stalls and leave zombie process
From: Holger Parplies <wbppc AT parplies DOT de>
To: Jim Leonard <trixter AT oldskool DOT org>
Date: Mon, 24 Aug 2009 04:17:49 +0200
Hi,

Jim Leonard wrote on 2009-08-23 20:04:31 -0500 [Re: [BackupPC-users] 
BackupPC_dump stalls and leave zombie process]:
> Steve wrote:
> > ---------------------
> > Aug 23 11:23:38 vaccg1 kernel: [ 1890.496217] BackupPC_dump[3888]:
> > segfault at bf23293c ip b7e249ea sp bfe92850 error 4 in
> > libz.so.1.2.3.3[b7e19000+14000]
> > ----------------------
> 
> Seems pretty obvious that the problem isn't free memory but rather some 
> bug in the interaction between backuppc_dump and libz.

"pretty obvious" as in "completely explains"? So, you are experiencing the
same behaviour? Or, at least, know of someone else that has, ever?

http://www.catb.org/~esr/faqs/smart-questions.html#id306810

> When it dies, there is a core file left behind;

Is there? Well, there might be, and looking at the stack trace might even be a
good idea (though you almost definitely will *not* find out ...

> what part of backuppc_dump you were in to cause it

... because you'll see a C backtrace - probably of stripped code -, not a Perl
backtrace, and Perl code cannot "cause" a SEGV anyway, only a bug in Perl or a
module (part) implemented in C can). Do that if you like, but it is certainly
not mandatory.

I'd either try replacing libz.so.1.2.3.3 with an uncorrupted copy (check the
md5sum of that file if you can; it may not, in fact, be a corrupted libz, but
that's where I'd start looking), if the SEGV happens roughly at the same place
each time, or else think about the possibility of hardware issues (memory, CPU,
I/O, PSU, ...; are you observing any other unexplained problems?). I wouldn't
go so far as to say any of that was obvious, let alone the only possible
explanation.

Hope that helps.

Regards,
Holger

P.S.: I wouldn't discount running out of memory as a possible cause for a
      SEGV. It was a good idea to check that.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/

<Prev in Thread] Current Thread [Next in Thread>