• 1
  • 125
  • 126
  • 127(current)
  • 128
  • 129
  • 218
v17 LibreELEC Testbuilds for RaspberryPi (Kodi 17.0)
nvm need to install the crashing build, doh
(2016-08-26, 17:37)Milhouse Wrote: Would it be possible for a process/thread to corrupt the call stack?

Yes. gdb will use use the current PC and SP and try to unwind them.
If either have been corrupted then you might expect garbage out.
Normally it is obviously garbage (like just a single entry as unwinding fails sanity checks) but I guess if you are unlucky it could produce some vaguely correct looking.
With controller:

Code:
Thread 1 (Thread 0x729ff3a0 (LWP 529)):
#0  0x751cd1cc in ioctl () at ../sysdeps/unix/syscall-template.S:84
#1  0x75073c08 in vchiq_queue_message () from /usr/lib/libvchiq_arm.so
#2  0x746b5868 in ilcs_execute_function_ex () from /usr/lib/libopenmaxil.so
#3  0x746b6648 in ilcs_execute_function () from /usr/lib/libopenmaxil.so
#4  0x746b7064 in vcil_out_get () from /usr/lib/libopenmaxil.so
#5  0x3e611880 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

without controller:
Code:
Thread 1 (Thread 0x74e80000 (LWP 490)):
#0  0x7512dc74 in nanosleep () at ../sysdeps/unix/syscall-template.S:84
#1  0x7515b36c in usleep (useconds=<optimized out>) at ../sysdeps/posix/usleep.c:32
#2  0x00457360 in CGraphicContext::Flip (this=this@entry=0x2612a88, rendered=rendered@entry=false, videoLayer=<optimized out>) at GraphicContext.cpp:986
#3  0x007a32e8 in CApplication::Render (this=0x2611788) at Application.cpp:1948
#4  0x00469714 in CGUIWindowManager::ProcessRenderLoop (this=0x2613f50, renderOnly=renderOnly@entry=false) at GUIWindowManager.cpp:1199
#5  0x0045a900 in CGUIDialog::Open_Internal (this=0x29f5138, bProcessRenderLoop=<optimized out>, param=...) at GUIDialog.cpp:197
#6  0x0045a410 in CGUIDialog::Open (this=this@entry=0x29f5138, param=...) at GUIDialog.cpp:211
#7  0x005a1380 in CGUIDialogOK::ShowAndGetInput (heading=..., text=...) at GUIDialogOK.cpp:57
#8  0x007aeb7c in CApplication::OnMessage (this=0x2611788, message=...) at Application.cpp:4191
#9  0x0046a9d8 in CGUIWindowManager::SendMessage (this=this@entry=0x2613f50, message=...) at GUIWindowManager.cpp:449
#10 0x0046ad5c in CGUIWindowManager::DispatchThreadMessages (this=0x2613f50) at GUIWindowManager.cpp:1348
#11 0x007afa64 in CApplication::Process (this=0x2611788) at Application.cpp:4470
#12 0x00804960 in CXBApplicationEx::Run (this=0x2611788) at XBApplicationEx.cpp:89
#13 0x006829bc in XBMC_Run (renderGUI=renderGUI@entry=true) at xbmc.cpp:89
#14 0x00363eac in main (argc=5, argv=0x7edd4774) at main.cpp:94
@BigNoid could you run the same two tests with #0826x?
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
@Milhouse yeah did that the first try (edited my post afterwards) those both ended normally.
TV set 50Hz, adjust display refresh is off, sync to display is on, passthru off, i.e. playback 24>25 fps with resampling audio. After 5-20min get a dead freeze. Sometimes with reboot.
http://sprunge.us/SPje
(2016-08-26, 19:10)MONSTA Wrote: TV set 50Hz, adjust display refresh is off, sync to display is on, passthru off, i.e. playback 24>25 fps with resampling audio. After 5-20min get a dead freeze. Sometimes with reboot.
http://sprunge.us/SPje

Possibly the atempo bug. Looks to be writing beyond edge of a malloc buffer.
Can you set atempo like the suggestion here.
(2016-08-26, 19:02)BigNoid Wrote: @Milhouse yeah did that the first try (edited my post afterwards) those both ended normally.

OK so...

#0825x: PR10299 (and commits from peripheral.joystick) with controller plugged in -> corrupt stack.

#0826x: *Reverted* PR10299 (and commits from peripheral.joystick), with controller plugged in -> normal stack.

I've got a build based on gcc6.2 which supports stack protection, I need to rustle up a debug-enabled build but if you can test that later this evening then that might give us more of a clue as to what is causing (presumably) the stack corruption - best guess at the moment is that we're only seeing the aftermath of the corruption, but not what has caused it.

I'll ping @garbear just in case he has any insight...
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
New LibreELEC.tv Krypton build #0826: RPi / RPi2
(Supercedes previous build)

Code:
# uname -a
Linux rpi512 4.7.2 #1 Fri Aug 26 19:48:52 BST 2016 armv6l GNU/Linux

# vcgencmd version
Aug 23 2016 15:58:54
Copyright (c) 2012 Broadcom
version f23e65aeeffca65654550c93254a0ee55f34fb07 (clean) (release)

# lsb_release
LibreELEC (Milhouse) - Version: devel-20160826222341-#0826-ga0e3207 [Build #0826]

# vcdbg log msg 2>&1 | grep DTOK
002386.245: Kernel trailer DTOK property says yes

# Kernel device tree status: Enabled

Based on tip of LibreELEC.tv master (a0e32078, changelog) and tip of XBMC master (a56be148, changelog) with the following modifications: Build Highlights:
  1. Revert to ondemand governor from schedutil
  2. Updated peripheral.joystick Deadzone settings
Build Details:
  1. LibreELEC.tv:
    • Odroid_C2: 64_bit_omx_pts (c108863c)
    • linux: update Odroid_C2 kernel to 365fa20 and tweak config (b4277bf0)
    • init: mount per-client boot/disk if available & configured (#621) (a0e32078)
  2. XBMC:
    • Deadzone settings (PR:10309, 7 commits, 20 files changed)
  3. peripheral.joystick:
    • Remove deadzone setting (PR:48, 1 commit, 4 files changed)
  4. Additional commits/pull requests/changes not yet merged upstream:
    • Exclude [env] kodi-999.99-PR10309.patch: merged upstream
    • Added: [env] PR:657: ffmpeg: add indev x11grab_xcb
    • Added: [env] PR:663: image: fakeroot chokes on image names with meta chars
    • Reverted: [env] PR:910a3f1b904b26c535e1826f0987268b3e128336: Generic/RPi2: Switch to schedutil CPUFreq governor (reverted: might result in sluggish performance)
    • Added: [pkg] patch: drm/i915: Limit the depth of the display pipeline to the framebuffer (linux)
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
(2016-08-26, 19:40)popcornmix Wrote: Possibly the atempo bug. Looks to be writing beyond edge of a malloc buffer.
Can you set atempo like the suggestion here.

Threshold 100 seems like ok.
Thank you
@BigNoid can you test another debug build, #0826y: RPi2

This is a build with gcc-6.2, stack protection and several other core package updates (glibc, binutils etc. etc.). Some addons may not work due to the change of compiler and other packages, in which case a clean ".kodi" may be the best test environment when grabbing the stacktrace.
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Hi,

even though there have been some deinterlacing and pvr fixes in the recent builds, the issue when switching from a 1080i to a 720p live channel still results in stuttery playback of the 720p channel with lots of frame skips.
Disabling deinterlace fixes this. So it appears that the deinterlacing is not stopped for the 720p content.
The last good build is still 0726.
(2016-08-27, 07:47)Milhouse Wrote: @BigNoid can you test another debug build, #0826y: RPi2

This is a build with gcc-6.2, stack protection and several other core package updates (glibc, binutils etc. etc.). Some addons may not work due to the change of compiler and other packages, in which case a clean ".kodi" may be the best test environment when grabbing the stacktrace.

Just tried with the regular #826 build and that ended normally. Maybe #10309 fixed the issue. I'll know more in a few hours. If it crashes again I'll use the y build. Thx in any case Smile
(2016-08-27, 09:04)niwa2 Wrote: Hi,

even though there have been some deinterlacing and pvr fixes in the recent builds, the issue when switching from a 1080i to a 720p live channel still results in stuttery playback of the 720p channel with lots of frame skips.
Disabling deinterlace fixes this. So it appears that the deinterlacing is not stopped for the 720p content.
The last good build is still 0726.

That's right, the picture is good only if deinterlacing is disabled, otherwise the picture there are disturbances, block noise, artifacts etc. Currently running build # 0826.
Other thing, when I in Settings Language German Choose, comes under Unit format / region default format "Belgium" and not Germany, but it was always like that, is this a bug?
[3x RPi3]#[ AV Receiver - Marantz NR1506 ]#[ TV Panasonic TX-50EXW784 ]#[ NAS - OMV 4.1.xx (Arrakis) @ NanoPI M4 ]#[ Nextcloud 17.0.3 @ ODROID C2 ]
With #826y still corrupted stack:
Code:
Thread 1 (Thread 0x55baf3a0 (LWP 6096)):
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:58
#1  0x75096400 in __GI_abort () at abort.c:89
#2  0x750ce890 in __libc_message (do_abort=do_abort@entry=2, fmt=<optimized out>) at ../sysdeps/posix/libc_fatal.c:175
#3  0x75148e8c in __GI___fortify_fail (msg=0x751836b4 "buffer overflow detected") at fortify_fail.c:30
#4  0x75147060 in __GI___chk_fail () at chk_fail.c:28
#5  0x75148e08 in __fdelt_chk (d=<optimized out>) at fdelt_chk.c:25
#6  0x0087a3c0 in NPT_BsdSocketFd::WaitForCondition (this=0x2bc6a80, wait_for_readable=wait_for_readable@entry=true, wait_for_writeable=wait_for_writeable@entry=false, async_connect=async_connect@entry=false, timeout=60000) at Neptune/Source/System/Bsd/NptBsdSockets.cpp:774
#7  0x0087a914 in NPT_BsdSocketFd::WaitUntilReadable (this=<optimized out>) at Neptune/Source/System/Bsd/NptBsdSockets.cpp:737
#8  0x0087aa4c in NPT_BsdSocketInputStream::Read (this=0x6af7b4c8, buffer=0x73cfef60, bytes_to_read=4096, bytes_read=bytes_read@entry=0x6af50ddc) at Neptune/Source/System/Bsd/NptBsdSockets.cpp:914
#9  0x0088ef1c in NPT_BufferedInputStream::FillBuffer (this=0x6af50db0) at Neptune/Source/Core/NptBufferedStreams.cpp:139
#10 0x0088ebd0 in NPT_BufferedInputStream::ReadLine (this=0x6af50db0, buffer=0x6af49c00 "", size=<optimized out>, chars_read=0x55baeb90, break_on_cr=false) at Neptune/Source/Core/NptBufferedStreams.cpp:226
#11 0x0088f118 in NPT_BufferedInputStream::ReadLine (this=this@entry=0x6af50db0, line=..., max_chars=max_chars@entry=8192, break_on_cr=break_on_cr@entry=false) at Neptune/Source/Core/NptBufferedStreams.cpp:268
#12 0x0086733c in NPT_HttpRequest::Parse (stream=..., endpoint=0x7ef38000, endpoint@entry=0x55baec64, request=@0x55baeccc: 0x0) at Neptune/Source/Core/NptHttp.cpp:768
#13 0x00a8c58c in PLT_HttpServerSocketTask::Read (this=this@entry=0x3022820, buffered_input_stream=..., request=@0x55baeccc: 0x0, context=context@entry=0x55baecf4) at Platinum/Source/Core/PltHttpServerTask.cpp:175
#14 0x00a8ccc8 in PLT_HttpServerSocketTask::DoRun (this=0x3022820) at Platinum/Source/Core/PltHttpServerTask.cpp:103
#15 0x0088b998 in PLT_ThreadTask::Run (this=0x3022820) at Platinum/Source/Core/PltThreadTask.cpp:179
#16 0x0087d99c in NPT_PosixThread::EntryPoint (argument=0x2f47578) at Neptune/Source/System/Posix/NptPosixThreads.cpp:481
#17 0x76d2cf40 in start_thread (arg=0x55baf3a0) at pthread_create.c:335
#18 0x75137e18 in ?? () at ../sysdeps/unix/sysv/linux/arm/clone.S:86 from /lib/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

I am just gonna unplug the controller now Big Grin
  • 1
  • 125
  • 126
  • 127(current)
  • 128
  • 129
  • 218

Logout Mark Read Team Forum Stats Members Help
LibreELEC Testbuilds for RaspberryPi (Kodi 17.0)19