Re: issues in cvs

Ok.  I tried adding certain fixes with just the cvs pull (the big fixes 
that seemed to be make or break my entire patch) but it simply would not 
work without the lock changes.  I realize the lock changes change 
purpose of having locks the way they are in most subsystems...but i dont 
think those locks were very necessary and in fact hindered zinf in more 
than one way.

i'm more than concerned that this patch doesn't work for everyone so i'd 
  like people to try out the latest zinf.  that means delete the old 
tree, get the new one.  People have been having issues because they dont 
watch the cvs download to see if any M's show up and then when they 
build it and it crashes they have no idea why it doesn't crash for 
anyone else.  So to make it easier on developers, either delete the tree 
before pulling or really watch your what cvs is telling you when you run 
update -Pd

I'm crossing my fingers and hoping this does the trick.  If it doesn't 
then we really need rethink some things from the foundation point of 
view because i know exactly what causes the deadlock, but exactly where 
the trigger is located is hard to find because it's closely related to 
the way we use signals to do things in parallel.

Try it out. tell me what you think. I've only worked on soundcard output 
and alsa output.  esound/arts and other OS's may not be fixed.  but tell 
me if they are or not.  I've tested it with -O0 and -o3 
-march=athlon-tbird -m3dnow and it worked.

If this is a winner then i'm going to go back to my code cleaning and 
such things to prep the tree for it's eventual release.

Re: issues in cvs

Just so you know your not talking to yourself. I have fetched current
CVS and compiled it.

It works great for ogg files, and for mp3 files that are already in the
musiccatalog. However I am getting a consitent seqfault when doing a
search for music, or when explicitly opening, previously unseen mp3's.

I will attach a backtrace, but as far as I can see, the pBuffer used by
XingLMC::BeginRead is no longer allocated anywhere.

The esd output plugin does seem to work.

Rob

#0  0x40228063 in memcpy () from /lib/libc.so.6
#1  0x4021d538 in _IO_file_xsputn () from /lib/libc.so.6
#2  0x4021e169 in _IO_sgetn () from /lib/libc.so.6
#3  0x40213e03 in fread () from /lib/libc.so.6
#4  0x402eb72d in XingLMC::BeginRead(char*&, unsigned) (this=0x933c858,
    pBuffer=@0xbe7fc2c8, iBytesNeeded=4323) at lmc/xingmp3/src/xinglmc.cpp:965
#5  0x402e9b7c in XingLMC::GetHeadInfo() (this=0x933c858)
    at lmc/xingmp3/src/xinglmc.cpp:242
#6  0x402ea60b in XingLMC::GetBitstreamStats(float&, float&, int&, int&, int&)
    (this=0x933c858, fTotalSeconds=@0xbe7fc378, fMsPerFrame=@0xbe7fc37c,
    iTotalFrames=@0xbe7fc380, iSampleRate=@0xbe7fc384, iLayer=@0xbe7fc388)
    at lmc/xingmp3/src/xinglmc.cpp:407
#7  0x402ea7f2 in XingLMC::CalculateSongLength(char const*) (this=0x933c858,
    szUrl=0x920bf5c
"file:///mnt/e/mp3z/quench/greenbelt_preview_2002/02-heaven_s_strength.mp3") at lmc/xingmp3/src/xinglmc.cpp:515

Re: issues in cvs

I was able to recreate the bug and this latest cvs commit seems to fix 
it. Try it out.

somewhat unfortunately, my kernel caches all of filesystem data for my 
music filesystem and subsequent attempts dont seem to touch the disc at 
all and work completely from ram, even if it's a new zinf and i delete 
the database it creates on just loading.

Robert Hart wrote:
> Just so you know your not talking to yourself. I have fetched current
> CVS and compiled it.
> 
> It works great for ogg files, and for mp3 files that are already in the
> musiccatalog. However I am getting a consitent seqfault when doing a
> search for music, or when explicitly opening, previously unseen mp3's.
> 
> I will attach a backtrace, but as far as I can see, the pBuffer used by
> XingLMC::BeginRead is no longer allocated anywhere.
> 
> The esd output plugin does seem to work.
> 
> Rob
> 

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: issues in cvs

I've been thinking of some long term solutions to our locking troubles

http://world.std.com/~jimf/papers/c++sync/c++sync.html#RWLock

that seems to be exactly what we want.

Ed Sweetman wrote:
> 
> I was able to recreate the bug and this latest cvs commit seems to fix 
> it. Try it out.
> 
> somewhat unfortunately, my kernel caches all of filesystem data for my 
> music filesystem and subsequent attempts dont seem to touch the disc at 
> all and work completely from ram, even if it's a new zinf and i delete 
> the database it creates on just loading.
> 
> 
> Robert Hart wrote:
> 
>> Just so you know your not talking to yourself. I have fetched current
>> CVS and compiled it.
>>
>> It works great for ogg files, and for mp3 files that are already in the
>> musiccatalog. However I am getting a consitent seqfault when doing a
>> search for music, or when explicitly opening, previously unseen mp3's.
>>
>> I will attach a backtrace, but as far as I can see, the pBuffer used by
>> XingLMC::BeginRead is no longer allocated anywhere.
>>

Re: issues in cvs

On Sat, 2003-03-01 at 17:50, Ed Sweetman wrote:
> I was able to recreate the bug and this latest cvs commit seems to fix 
> it. Try it out.
> 
> somewhat unfortunately, my kernel caches all of filesystem data for my 
> music filesystem and subsequent attempts dont seem to touch the disc at 
> all and work completely from ram, even if it's a new zinf and i delete 
> the database it creates on just loading.

That seems to help a lot - I now have my music catalogue back. I have
had two seq faults during the search though, (back traces attached),
although I haven't had time to investigate them, or to see how
reproduceable they are.

Thanks for the work you've been doing.

Rob

#0  0x40223460 in mallopt () from /lib/libc.so.6
#1  0x40222e80 in mallopt () from /lib/libc.so.6
#2  0x40222145 in malloc () from /lib/libc.so.6
#3  0x40166c82 in operator new(unsigned) () from /usr/lib/libstdc++.so.5
#4  0x40166db3 in operator new[](unsigned) () from /usr/lib/libstdc++.so.5
#5  0x0806c71d in MusicCatalog::WriteMetaDataToDatabase(char const*, MetaData,
MetadataStorageType) (this=0x80c0140,
    url=0x91973b4
"file:///mnt/e/mp3z/the_beatles/sgt_pepper_s_lonely_hearts_club_band/05-fixing_a_hole.mp3", metadata=
      {_vptr.MetaData = 0x80a2638, m_artist = {static npos = 4294967295, _M_dataplus = {<allocator<char>> =
{<No data fields>}, _M_p = 0x9203454 "The Beatles"}, static _S_empty_rep_storage = {0, 0, 0, 0}},

Re: issues in cvs

Robert Hart wrote:
> On Sat, 2003-03-01 at 17:50, Ed Sweetman wrote:
> 
>>I was able to recreate the bug and this latest cvs commit seems to fix 
>>it. Try it out.
>>
>>somewhat unfortunately, my kernel caches all of filesystem data for my 
>>music filesystem and subsequent attempts dont seem to touch the disc at 
>>all and work completely from ram, even if it's a new zinf and i delete 
>>the database it creates on just loading.
> 
> 
> That seems to help a lot - I now have my music catalogue back. I have
> had two seq faults during the search though, (back traces attached),
> although I haven't had time to investigate them, or to see how
> reproduceable they are.
> 
> Thanks for the work you've been doing.
> 
> Rob

I'm not sure if you gave your compiler info before and all.  But I 
really cannot recreate this error. I'm making fixes blindly seeing if 
some extra checks and locks help things. They dont break my tree, so i'm 
going to commit them so you can try it out.

> ------------------------------------------------------------------------
> 
> #0  0x40223460 in mallopt () from /lib/libc.so.6
> #1  0x40222e80 in mallopt () from /lib/libc.so.6

Re: issues in cvs

debian updates the compiler and now the goddamn way zinf works changes.

We definitely need to change the damn Mutex class to a read and write 
method.

All that goddamn lock work for nothing it seems since having any of it 
make a difference is completely by chance due to compiler/linking.

Ed Sweetman wrote:
> Robert Hart wrote:
> 
>> On Sat, 2003-03-01 at 17:50, Ed Sweetman wrote:
>>
>>> I was able to recreate the bug and this latest cvs commit seems to 
>>> fix it. Try it out.
>>>
>>> somewhat unfortunately, my kernel caches all of filesystem data for 
>>> my music filesystem and subsequent attempts dont seem to touch the 
>>> disc at all and work completely from ram, even if it's a new zinf and 
>>> i delete the database it creates on just loading.
>>
>>
>>
>> That seems to help a lot - I now have my music catalogue back. I have
>> had two seq faults during the search though, (back traces attached),
>> although I haven't had time to investigate them, or to see how
>> reproduceable they are.
>>
>> Thanks for the work you've been doing.

Re: issues in cvs

On Sat, 2003-03-01 at 17:50, Ed Sweetman wrote:
> I was able to recreate the bug and this latest cvs commit seems to fix 
> it. Try it out.
> 
> somewhat unfortunately, my kernel caches all of filesystem data for my 
> music filesystem and subsequent attempts dont seem to touch the disc at 
> all and work completely from ram, even if it's a new zinf and i delete 
> the database it creates on just loading.
> 

Just been looking over latest commit to musiccatalog.cpp (rev 1.11). It
seems that every method that once acquired the m_mutex now creates its
own Mutex (also called m_mutex, thus hiding the instance variable) and
acquires it. This means that every method call gets a different mutex...
kinda defeats the point, no?

--

-- 
Michael Hall <michaelhall <at> btinternet.com>
'Time is an illusion. Lunchtime doubly so' -- H2G2

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: issues in cvs

Michael Hall wrote:
> On Sat, 2003-03-01 at 17:50, Ed Sweetman wrote:
> 
>>I was able to recreate the bug and this latest cvs commit seems to fix 
>>it. Try it out.
>>
>>somewhat unfortunately, my kernel caches all of filesystem data for my 
>>music filesystem and subsequent attempts dont seem to touch the disc at 
>>all and work completely from ram, even if it's a new zinf and i delete 
>>the database it creates on just loading.
>>
> 
> 
> Just been looking over latest commit to musiccatalog.cpp (rev 1.11). It
> seems that every method that once acquired the m_mutex now creates its
> own Mutex (also called m_mutex, thus hiding the instance variable) and
> acquires it. This means that every method call gets a different mutex...
> kinda defeats the point, no?
> 

you'd think so.  but I haven't seen any adverse effects from it and it 
actually follows scope so it doesn't deadlock.

The way i have made changes is no worse by far than the old way of 
doing things.  What we need to do is strip our mutexes completely out of 
zinf, make Mutexes that make goddamn sense for zinf that are actually 
thread safe. Then maybe sending events at less than 10ms apart wont 
confuse the hell out of zinf and lock up the input plugin.

Of course if you want to get technical, the reason why the input plugin 

Re: issues in cvs

On Sun, 2003-03-02 at 11:27, Ed Sweetman wrote:
> Michael Hall wrote:
> > On Sat, 2003-03-01 at 17:50, Ed Sweetman wrote:
> > 
> >>I was able to recreate the bug and this latest cvs commit seems to fix 
> >>it. Try it out.
> >>
> >>somewhat unfortunately, my kernel caches all of filesystem data for my 
> >>music filesystem and subsequent attempts dont seem to touch the disc at 
> >>all and work completely from ram, even if it's a new zinf and i delete 
> >>the database it creates on just loading.
> >>
> > 
> > 
> > Just been looking over latest commit to musiccatalog.cpp (rev 1.11). It
> > seems that every method that once acquired the m_mutex now creates its
> > own Mutex (also called m_mutex, thus hiding the instance variable) and
> > acquires it. This means that every method call gets a different mutex...
> > kinda defeats the point, no?
> > 
> 
> you'd think so.  but I haven't seen any adverse effects from it and it 
> actually follows scope so it doesn't deadlock.

Given that everytime a method is called a new mutex is allocated off the
stack, I'm not surprised you don't get any deadlocks. You might as well
remove them completely. All they're doing now is slowing the code down
by acquiring a lock that it just created and no other code path is ever
going to see.