2014-09-10, 18:58
for the record: no need to clone, just add an additional remote to git. saves traffic on github 
2014-09-10, 19:01
i'm sorry, but i have no knowledge about git. your suggestion makes no sense to me 
i just know to clone, clean up etc.
i'm a long long year dev myself, but never used git for anything, neither gdb. my larger projects were (sadly) not for linux platforms.
i just know to clone, clean up etc.
i'm a long long year dev myself, but never used git for anything, neither gdb. my larger projects were (sadly) not for linux platforms.
2014-09-10, 19:37
ok, with your git it indeed seems to be much more stable now. but i still managed to crash kodi with seeking. i'll report back with details after dinner
2014-09-10, 20:05
so, here it is, gdb all threads backtrace and the xbmc log in debug mode:
https://drive.google.com/folderview?id=0...sp=sharing
The version from FernetMentas master branch is indeed MUCH more stable regardnig seeking. i had to seek forward and backward like mad until i managed to crash kodi.
it seems like there is a race condition with threads. there is some code not properly made thread safe and with bad luck or excessive seeking you can run into it.
i'm now away for some hours. but i will check later if there is something else i can do to help pinning this down.
at least i can give a little back with this to this great peace of software i enjoy for years
https://drive.google.com/folderview?id=0...sp=sharing
The version from FernetMentas master branch is indeed MUCH more stable regardnig seeking. i had to seek forward and backward like mad until i managed to crash kodi.
it seems like there is a race condition with threads. there is some code not properly made thread safe and with bad luck or excessive seeking you can run into it.
i'm now away for some hours. but i will check later if there is something else i can do to help pinning this down.
at least i can give a little back with this to this great peace of software i enjoy for years
2014-09-10, 20:57
it crashes somewhere in mesa i965_dri.so whle deleting a texture
if (glIsTexture(pic->texture))
{
glDeleteTextures(1, &pic->texture); <---------------- here
glXDestroyPixmap(m_Display, pic->glPixmap);
XFreePixmap(m_Display, pic->pixmap);
}
so I fist ask the driver if the texture is valid, it. says yes, then it segfaults
not nice
can you reproduce this with trusty? utopic might be a bit too unstable currently. just to narrow it down.
if (glIsTexture(pic->texture))
{
glDeleteTextures(1, &pic->texture); <---------------- here
glXDestroyPixmap(m_Display, pic->glPixmap);
XFreePixmap(m_Display, pic->pixmap);
}
so I fist ask the driver if the texture is valid, it. says yes, then it segfaults
not nicecan you reproduce this with trusty? utopic might be a bit too unstable currently. just to narrow it down.
2014-09-11, 02:35
yes i could reproduce this with trusty when i had it. but i cannot anymore because i do not have the possibility to install it again, sorry.
note: utopic had until yesterday or so stil a much older graphics stack/driver. it still happend with it. but you see now the probplem after updating to the new one.
--------------------------------------------------------------------
EDIT:before this update it was i915 driver and not i965.
---------------------------------------------------------------------
sorry that i can't do more as it seems.
anyhow, i see that threads are started when seeking. not sure what they do so this may be a stupid question:
but could it be that you ask the driver for validity of the texture but when you actually use it it is a different one, altered by another thread?
the reason i ask is because it only seems to happen rarly (at least in your version) and only when seeking forward and backward like mad.
if it would be just a driver bug making a mistake about the validity then it should be reproducable even when using seek only rarly, like a normal usae case. or?
note: utopic had until yesterday or so stil a much older graphics stack/driver. it still happend with it. but you see now the probplem after updating to the new one.
--------------------------------------------------------------------
EDIT:before this update it was i915 driver and not i965.
---------------------------------------------------------------------
sorry that i can't do more as it seems.
anyhow, i see that threads are started when seeking. not sure what they do so this may be a stupid question:
but could it be that you ask the driver for validity of the texture but when you actually use it it is a different one, altered by another thread?
the reason i ask is because it only seems to happen rarly (at least in your version) and only when seeking forward and backward like mad.
if it would be just a driver bug making a mistake about the validity then it should be reproducable even when using seek only rarly, like a normal usae case. or?
2014-09-11, 17:55
only a single thread does access this. a problem may be that shared gl contexts in mesa is a mess. when did you last update to my branch. i changed the code above and explicitly set pic->pixmap to None.
2014-09-11, 17:57
hmm, not sure, somewhere last night. but i had some issues here so i maybe messed up stuff (i mean my copy of your source).
mind tell we the file/line where you did the change and i can check if its there?
mind tell we the file/line where you did the change and i can check if its there?
2014-09-11, 18:26
2014-09-11, 19:43
yes i have that. and i tried to crash kodi. i didn't managed to crash it with seeking.
seems fixed.
seems fixed.
2014-09-11, 19:47
good to hear.
btw: currently I do long term tests with 1080i@50 using MCDI. I observe really strange things I can't explain with Trusty + kernel 3.16.1 + libva-intel-vaapi-driver fro mwsnipex ppa. today I went back to kernel 3.15.10 and haven't seen any issue for the last two hours.
btw: currently I do long term tests with 1080i@50 using MCDI. I observe really strange things I can't explain with Trusty + kernel 3.16.1 + libva-intel-vaapi-driver fro mwsnipex ppa. today I went back to kernel 3.15.10 and haven't seen any issue for the last two hours.
2014-09-11, 20:14
there's a new driver and libva in that ppa now. Lets hope it doesn't change for the worse
2014-09-11, 22:59
back again
i am back to utopic stock libs again. i want to keep that until it is officially released and stabilized and then switching to oibaf or what ever i'm in the mood to experiment with
anyhow, glad this issue is fixed and that i could somehow help with it.
now i gonna enjoy a nice movie with kodi. i use it as my all in one home entertainment, tv movies, music.
though living with the git version always causes sometimes trouble
i am back to utopic stock libs again. i want to keep that until it is officially released and stabilized and then switching to oibaf or what ever i'm in the mood to experiment with
anyhow, glad this issue is fixed and that i could somehow help with it.
now i gonna enjoy a nice movie with kodi. i use it as my all in one home entertainment, tv movies, music.
though living with the git version always causes sometimes trouble
2014-09-12, 04:27
just a final question on this topic:
is there an eta when the fixes are getting merged into kodi main master branch?
is there an eta when the fixes are getting merged into kodi main master branch?
