From 1be510f9529cb082f802408b472a77d074b394c0 Mon Sep 17 00:00:00 2001 From: Nicolas Vigier Date: Sun, 14 Apr 2013 13:46:12 +0000 Subject: Add zarb MLs html archives --- zarb-ml/mageia-dev/2011-August/007652.html | 139 +++++++++++++++++++++++++++++ 1 file changed, 139 insertions(+) create mode 100644 zarb-ml/mageia-dev/2011-August/007652.html (limited to 'zarb-ml/mageia-dev/2011-August/007652.html') diff --git a/zarb-ml/mageia-dev/2011-August/007652.html b/zarb-ml/mageia-dev/2011-August/007652.html new file mode 100644 index 000000000..57f63313d --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007652.html @@ -0,0 +1,139 @@ + + + + [Mageia-dev] Our BS is about to eat packages? + + + + + + + + + +

[Mageia-dev] Our BS is about to eat packages?

+ nicolas vigier + boklm at mars-attacks.org +
+ Mon Aug 29 17:06:19 CEST 2011 +

+
+ +
On Mon, 29 Aug 2011, Michael Scherer wrote:
+
+> Le lundi 29 août 2011 à 13:47 +0200, Michael Scherer a écrit :
+> > Le lundi 29 août 2011 à 08:02 +0200, D.Morgan a écrit :
+> > > On Mon, Aug 29, 2011 at 6:21 AM, Funda Wang <fundawang at gmail.com> wrote:
+> > > > Hello,
+> > > >
+> > > > It looks like our BS is becoming hungry to eat built packages:
+> > > > Submitted       User    Package Target  Media   Status  Build time
+> > > > 18 hours ago    wally   libcanberra-0.28-3.mga2 cauldron        core/release            uploaded        15215
+> > > > days
+> > > > 23 hours ago    fwang   gnome-python-extras-2.25.3-27.mga2      cauldron        core/release            uploaded        15215
+> > > > days
+> > > > 1 day ago       fwang   libnotify-0.7.4-1.mga2  cauldron        core/release            partial
+> > > >
+> > > > Could somebody give a look at the issue? And I think BS is much slower
+> > > > than the past. In the past, most packages were built succesfully
+> > > > within less than 5 minutes, but now > 10 minutes.
+> > > >
+> > > > Thanks.
+> > > >
+> > > 
+> > > I don't recall seeing such issues on the BS before maybe misc can have an idea
+> > > and, we only have one node for the moment ( ecosse is disabled ) this
+> > > explain why it is slower.
+> > 
+> > After looking at the problem, I suspect it could be linked to texmf.
+> > Each time iurt install it, the process stop.  
+> > 
+> > Yet, I have no more idea, and couldn't investigate further for now.
+> 
+> Boklm found the problem, it was urpmi segfaulting.
+> 
+> We remove the chroot, and thing seems to be ok now again.
+
+But we probably still have the problem, as segfaults seems to be
+happenning not all the time.
+
+After succesfully reproducing the error using the old chroot and running
+urpmi several times, the backtrace :
+
+#0  0xf7405b29 in _int_malloc () from /lib/i686/libc.so.6
+#1  0xf7408177 in malloc () from /lib/i686/libc.so.6
+#2  0xf6eadfa8 in __os_malloc (env=0xb442db8, size=4149199776, storep=0xffbbf5cc) at ../os/os_alloc.c:253
+#3  0xf6eac47c in __memp_sync_int (env=0xb442db8, dbmfp=0xb893130, trickle_max=0, flags=8, wrote_totalp=0x0, interruptedp=0x0)
+    at ../mp/mp_sync.c:294
+#4  0xf6eacfaf in __memp_fsync (dbmfp=0xb893130) at ../mp/mp_sync.c:202
+#5  0xf6e3cdf9 in __db_sync (dbp=0xb8963e8) at ../db/db_am.c:706
+#6  0xf6e3aa68 in __db_refresh (dbp=0xb8963e8, txn=0x0, flags=0, deferred_closep=0xffbbf6fc, reuse=0) at ../db/db.c:819
+#7  0xf6e3adc5 in __db_close (dbp=0xb8963e8, txn=0x0, flags=0) at ../db/db.c:695
+#8  0xf6e52a38 in __db_close_pp (dbp=0xb8963e8, flags=0) at ../db/db_iface.c:253
+#9  0xf72fec45 in db3close (dbi=0xb893030, flags=0) at backend/db3.c:494
+#10 0xf73071c6 in dbiClose (db=0xb2b6950) at ../lib/rpmdb_internal.h:453
+#11 rpmdbClose (db=0xb2b6950) at rpmdb.c:852
+#12 0xf73379d6 in rpmtsCloseDB (ts=0xb231b20) at rpmts.c:64
+#13 0xf7337a48 in rpmtsFree (ts=0xb231b20) at rpmts.c:567
+#14 0xf736c7a1 in XS_URPM__DB_DESTROY (my_perl=0x8d42008, cv=0x8e2d420) at URPM.xs:2794
+#15 0xf765867d in Perl_pp_entersub (my_perl=0x8d42008) at pp_hot.c:3046
+#16 0xf75e1a0e in Perl_call_sv (my_perl=0x8d42008, sv=0x8e2d420, flags=45) at perl.c:2647
+#17 0xf765f21c in S_curse (my_perl=0x8d42008, orig_sv=0xb009b48) at sv.c:6346
+#18 Perl_sv_clear (my_perl=0x8d42008, orig_sv=0xb009b48) at sv.c:6077
+#19 0xf765fa3a in Perl_sv_free2 (my_perl=0x8d42008, sv=0xb009b48) at sv.c:6478
+#20 0xf760c46c in Perl_cv_undef (my_perl=0x8d42008, cv=0xb09a140) at pad.c:381
+#21 0xf765f604 in Perl_sv_clear (my_perl=0x8d42008, orig_sv=0xb13c088) at sv.c:6118
+#22 0xf765fa3a in Perl_sv_free2 (my_perl=0x8d42008, sv=0xb13c088) at sv.c:6478
+#23 0xf76477bc in Perl_hv_free_ent (my_perl=0x8d42008, hv=0x93f01f8, entry=0xb0313c8) at hv.c:1486
+#24 0xf7647aa4 in S_hfreeentries (my_perl=0x8d42008, hv=0x93f01f8) at hv.c:1803
+#25 0xf764c09b in Perl_hv_clear (my_perl=0x8d42008, hv=0x93f01f8) at hv.c:1559
+#26 0xf76893e5 in Perl_leave_scope (my_perl=0x8d42008, base=79) at scope.c:911
+#27 0xf7689463 in Perl_pop_scope (my_perl=0x8d42008) at scope.c:110
+#28 0xf7656c28 in Perl_pp_leavesub (my_perl=0x8d42008) at pp_hot.c:2626
+#29 0xf764f078 in Perl_runops_standard (my_perl=0x8d42008) at run.c:41
+#30 0xf75e7e59 in S_run_body (my_perl=0x8d42008) at perl.c:2345
+#31 perl_run (my_perl=0x8d42008) at perl.c:2268
+#32 0x08048c0e in main (argc=4, argv=0xffbbff94, env=0xffbbffa8) at perlmain.c:120
+
+
+ + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ -- cgit v1.2.1