Bug#190110: libc6: Sub-processes flaking out.
Hi,
At 22 Apr 2003 05:08:46 -0000,
mah@dsl093-249-203.chi3.dsl.speakeasy.net wrote:
> I'm not sure this is the right package to file against, but it
> feels like the closest thing.
>
> This bug is probably identical to #147183. That was marked as
> "unreproducable" and the thread on the bug indicates that
> everyone thought it was a hardware problem. I am seeing similar
> symptoms and have pretty much eliminated the possibility of a
> hardware problem.
>
> Symptoms:
> - Sub-processes for "debuild -uc -us" flakes out
> unpredictably. Sometimes it'll flake at dh_clean,
> sometimes at the .deb creation, sometimes on dh_fixperms,
> etc. Almost always flakes out, but rarely in the same
> place twice in a row. Sample output:
>
> make[2]: Entering directory `/virtual/everybody.org/user/mah/work/deb-src/gnus-CVS/texi'
> /bin/sh ../mkinstalldirs /virtual/everybody.org/user/mah/work/deb-src/gnus-CVS/debian/ognus/usr/share/info
> make[2]: *** wait: No child processes. Stop.
> make[2]: *** Waiting for unfinished jobs....
> make[2]: *** wait: No child processes. Stop.
> make[1]: *** [install] Error 2
> make[1]: Leaving directory `/virtual/everybody.org/user/mah/work/deb-src/gnus-CVS'
> make: *** [install] Error 2
> debuild: fatal error at line 456:
> dpkg-buildpackage failed!
>
> - Apache starts up normally during startup, but after startup
> it can't startup. Running "strace -o /tmp/t
> /usr/sbin/apache -F" and examining the last bit of the file
> generated shows:
>
> munmap(0x40018000, 4096) = 0
> munmap(0x40012000, 4096) = 0
> semget(1, 4096, 0x873b1e0|0640) = -1 ENOSYS (Function not implemented)
>
> - General aggrevation!
>
> So, why am I so sure that this isn't a hardware issue? I began
> seeing this problem on two separate machines. Both are set to
> apt-get from "stable" falling back to "testing" when necessary.
> I've upgraded to libc6 from "testing" on both. That seems to be
> when the problems started showing up.
>
> But that isn't proof enough.
>
> In one of the machines, I have a spare disk. I did new Debian
> install on that machine and then did a "dist-upgrade" to
> testing. The new install works flawlessly -- even compiling a
> kernel (my test for hardware problems).
>
> Perhaps it is a problem between the keyboard and the chair, but
> this feels like a problem in the upgrade process -- perhaps some
> dependencies are set wrong.
I tought from this bug report:
(1) Why do you think it's glibc bug? I don't still understand your
point.
(2) Randomly breakage is normally hardware bug. Well there are some
possibilities of software bug in gcc/glibc/binutils/kernel and
debian tools like debuild.
(3) If this bug is glibc, then almost debian guys should be caused
this problem, but I have no experiments of this kind of bug.
> Also, I should have mentioned that, in addition to the symptoms I
> described in the bug report, I'm seeing the same symptoms as reported
> in #147183 -- dpkg doesn't extract some files properly and reports tar
> as the culprit.
This seems very bad behavior. Did you try to test memory on your
machine? memtest86 is a good tool to check it. #147183 says:
> The fact that running tar (on anything) before running dpkg
> makes a difference indicates clearly that the problem was
> some sort of system flakiness.
This is very bad state. If you have this problem, the filesystem will
be totally unusable from my experiment with bad CPU which is weak of
temperature-resistant under high load.
Regards,
-- gotom
Reply to: