Re: Partimage: Problem with sched_yield()
On Wed, Nov 05, 2003 at 07:21:15PM +0100, Ruediger Scholz wrote:
> Matthew Wilcox schrieb:
>
> >
> >Try 'bt' for backtrace, that at least tells us where sched_yield()
> >is being called from.
> >
> OK, I tried 'bt' before but I got no useful output as you will see
> below. But now I tried 'bt full' and I get a lot of information. Hope
> it's more useful...
I'm seeing:
(gdb) bt
#0 0x401a5c9c in __pthread_acquire () from /lib/libpthread.so.0
#1 0x401a57a8 in __pthread_alt_lock () from /lib/libpthread.so.0
#2 0x401a2480 in pthread_mutex_lock () from /lib/libpthread.so.0
#3 0x000590ac in CXfsPart::getInfos() ()
#4 0x00031b40 in main ()
#5 0x405d944c in __libc_start_main () from /lib/libc.so.6
#6 0x00015528 in _init ()
(gdb)
We get into main. All the libraries are setup.
CXfsPart::getInfos() is the following
virtual void* getInfos() {return (void*)&m_info;}
I don't see any other derived classes. I also don't understand why the
Xfs object is being used when I'm trying to read an ext2 partition?
I don't particularly trust gdb and I'm goin to have to run one of my
'si' scripts against partimage to figure out what it's calling just
before the recursive acquire.
Anyone else have any other ideas?
c.
Reply to: