cvs commit: ports/net/dcgui Makefile distinfo ports/net/dcgui/files patch-main.cpp

[Ion-Mihai Tetcu]

On Fri, 27 Feb 2004 14:54:56 +0100
Markus Brueffer <markus at FreeBSD.org> wrote:

> On Friday 27 February 2004 14:34, Ion-Mihai Tetcu wrote:
> > On Fri, 27 Feb 2004 05:06:43 -0800 (PST)
[..]
> > Markus, could you please take a look at my:
> >
> > From: Ion-Mihai Tetcu <itetcu at apropo.ro>
> > To: ports at FreeBSD.ORG
> > Subject: net/dcgui locks machine hard - libpthread related
> > Date: Fri, 27 Feb 2004 13:25:47 +0200
> >
> > and perhaps give me an advice ? Thank you.
> 
> I'm currently looking into it. It's hard for me to debug, since I'm
> not able to reproduce this, neighter on -STABLE, nor on 5.2.1
> (libc_r). I noticed this sometimes in the past when I used Xinerama
> with two different graphic-devices. Since I'm using a NVidia TI 4200
> in dual-head mode (nvidia-driver), this hasn't occured anymore. Since
> noone else was able to reproduce this, I thought it was somehow
> related to my XFree-setup.

I have a  Radeon R250 If [Radeon 9000] rev 1, but I'm not using the
"fancy" features (no drm, etc.). 

> The question now is: what is responsible for the lockups? If the
> machine completly locks up, it can't be only a dcgui-thing. Obviously
> the threading-libs are somehow responsible for these lockups, or at
> least somehow involved. Any hints on how to track this down are
> welcome.

1. For now I have only empiric informations. I'll try to setup a serial
console next week (if the real life permits) and break to debugger when
it happens. Maybe that will give a clue.
It's an UP AthonXP machine. I'll try a kernel without SMP, maybe it make
a difference.

machine         i386
cpu             I686_CPU
ident           KSE_ULE_UP_apic
options         CPU_ATHLON_SSE_HACK
options         NPX_DEBUG
makeoptions     DEBUG=-g               
options         BREAK_TO_DEBUGGER
options         SCHED_ULE               #firts try, huh :)
options         HZ=1000
options         DDB              
options         INVARIANTS       
options         INVARIANT_SUPPORT
options         WITNESS       
options        SMP                     # Symmetric MultiProcessor Kernel
device          apic                    # I/O APIC

2. The system is stable without dcgui. 

3. I cannot understand why it was locking KDE/X *before* kse came in
with the s/-lpthread/${PTHREAD_LIBS}/g; I think it was happening after
the first output on the splash screen. A strange linuxism on how dcgui 
makes use of threads ?

4. It seems to lock when it has a large number of active concurrent
downloads (many sources for a few files) or when one closes about 10
downloads and shutdown dcgui, or only close downloads.. What if the
problem is in dclib, rather that dcgui and 3) is not related ? Should I
try profiling ? The bad thing is that I'm not familiar at all with qt.
 
> > Also I think that in dclib's pkg-plist:
> > @unexec rmdir %D/share/dcgui/plugin 2>/dev/null || true
> > @unexec rmdir %D/share/dcgui 2>/dev/null || true
> > are not needed, since the html plugin is now a separate thing and
> > dcgui does not install tehm. And dclib seems to install also:
> 
> see below
> 
> > + at dirrm share/nls/en_US.US-ASCII
> > + at dirrm share/nls/POSIX
> 
> nls-entries don't belong into the plist.

< BIG UPS>
I was using Tools/plist; I'll try again to convince myself it was an
pilot error ;-)

> > + at dirrm share/dcgui/plugin
> > + at dirrm share/dcgui
> 
> These two entries are essentially the same than the two above. The
> difference ist, that the above entries take care of not throwing
> error-messages, when these directories are not empty when deleting the
> pkg (which isn't neccessary the case).

Yes, I know. I was thinking that, because dcgui doesn't install
something in there, there is no reason for  @unexec. Do you have plans
to port the html plugin ?


-- 
IOnut
Unregistered ;) FreeBSD user