Hi,
with the latest version of the vompclient, I get again a seg fault. But now, I get it also if my TV is connected to hdmi. Here the debug log:
18:53:47.216400 [notice] 2435 Core - Startup successful
18:53:47.218336 [notice] 2435 Video - signalOn
18:53:47.220262 [debug] 2435 OSD - shutdown mark1
18:53:47.222887 [debug] 2435 Remote - CECLOG: 1651 16 received data: header:00030002 p0:00011A01 p1:00000000 p2:00000000 p3:00000000 reason:2
18:53:47.226295 [debug] 2435 Remote - CECLOG: 1654 8 >> 01:1a:01
18:53:47.228466 [debug] 2435 Remote - CECLOG: 1657 4 >> TV (0) -> Recorder 1 (1): give deck status (1A)
18:53:47.230655 [debug] 2435 Remote - CECLOG: 1659 4 << Recorder 1 (1) -> TV (0): deck status 'stop'
18:53:47.232800 [debug] 2435 Remote - CECLOG: 1661 8 << 10:1b:1a
18:53:47.236833 [debug] 2435 OSD - shutdown mark2
18:53:47.238824 [debug] 2435 Remote - CECLOG: 1667 16 sending data: len = 2, payload = 10:1B:1A
18:53:47.240868 [debug] 2435 OSD - shutdown mark3
18:53:47.243093 [debug] 2435 OSD - Making egl current out final
18:53:47.258028 [notice] 2435 Video - No CEA modes found abort
18:53:47.259663 [notice] 2435 OSD - OpenGL_ES OpenVG
18:53:47.261411 [notice] 2435 OSD - EGL_KHR_image EGL_KHR_image_base EGL_KHR_image_pixmap EGL_KHR_vg_parent_image EGL_KHR_gl_texture_2D
18:53:47.262989 [notice] 2435 OSD - _image EGL_KHR_gl_texture_cubemap_image EGL_KHR_lock_surface
18:53:47.266020 [notice] 2435 OSD - Displaysize is 1920 x 1080
18:53:47.284023 [debug] 2435 OSD - Making egl current in12435
18:53:47.285605 [notice] 2435 OSD - 1.1
18:53:47.287036 [notice] 2435 OSD - Broadcom
18:53:47.288681 [notice] 2435 OSD - VideoCore IV HW
18:53:47.290217 [notice] 2435 OSD - VG_KHR_EGL_image
18:53:47.331214 [debug] 2435 Remote - CECLOG: 1759 16 received data: header:00030001 p0:001A1B10 p1:00000000 p2:00000000 p3:00000000 reason:1
18:53:47.333800 [debug] 2435 Remote - CECLOG: 1762 16 command transmitted
18:53:47.452595 [debug] 2435 OSD - Making egl current out 12435
18:53:47.454571 [debug] 2435 BoxStack - Update called
18:53:47.456216 [debug] 2435 BoxStack - Locked for update
Segmentation fault
Claus
please set with ulimit -c unlimitedhe genaration of a core file.
Create a core file and excute
gdbtui vompclient core
and tell me where it crashes.
Marten
Hi,
I'm not sure, if I get the right information for you, but I will try it:
The source code window shows the file boxstack.cc line 287
Region r = toUpdate->area;
The message window shows:
[New LWP 2458]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
Cannot find new threads: generic error
Core was generated by `vompclient -s 127.0.0.1 -n'.
Program terminated with signal 11, Segmentation fault.
#0 0x0004d1c4 in BoxStack::update (this=<error reading variable: Cannot access memory at address 0xbea54bb4>,
toUpdate=<error reading variable: Cannot access memory at address 0xbea54bb0>,
regionToUpdate=<error reading variable: Cannot access memory at address 0xbea54bac>) at boxstack.cc:287
If this information is not enough, maybe the reason is, that I have striped the symbols from the vompclient.
Claus
Please test the following, add the following code before line 287;
if (!toUpdate) {
#ifndef WIN32
pthread_mutex_unlock(&boxLock);
#else
ReleaseMutex(boxLock);
#endif
Log::getInstance()->log("BoxStack", Log::DEBUG, "Unlocked for update, no box present");
return ;
and tell we if it works.
Marten
I have add a missing closing bracked at the end of your code.
Now I get this (also a seg fault):
...
09:49:18.041015 [debug] 2381 Remote - CECLOG: 1201 16 sending data: len = 3, payload = 1F:82:10:00
09:49:18.163098 [debug] 2381 Remote - CECLOG: 1323 16 received data: header:00040001 p0:0010821F p1:00000000 p2:00000000 p3:00000000 reason:1
09:49:18.163842 [debug] 2381 Remote - CECLOG: 1324 16 command transmitted
09:49:18.164259 [debug] 2381 Remote - CECLOG: 1325 4 << Recorder 1 (1) -> TV (0): menu state 'activated'
09:49:18.164682 [debug] 2381 Remote - CECLOG: 1325 8 << 10:8e:00
09:49:18.165407 [debug] 2381 Remote - CECLOG: 1326 16 sending data: len = 2, payload = 10:8E:00
09:49:18.256179 [debug] 2381 Remote - CECLOG: 1417 16 received data: header:00030001 p0:00008E10 p1:00000000 p2:00000000 p3:00000000 reason:1
09:49:18.256842 [debug] 2381 Remote - CECLOG: 1417 16 command transmitted
09:49:18.257549 [info] 2381 Core - Remote module initialised
09:49:18.257903 [info] 2381 Core - LED module initialised
09:49:18.258283 [info] 2381 Core - Mtd module initialised
09:49:18.258886 [info] 2381 Core - Timers module initialised
09:49:18.259280 [info] 2381 Core - Read from MTD: PAL 720x576
09:49:18.259623 [debug] 2381 Video - Setting aspect to 0
09:49:18.262339 [notice] 2381 Video - No CEA modes found abort
09:49:18.265827 [info] 2381 Core - Video module initialised
09:49:18.268778 [notice] 2381 OSD - OpenGL_ES OpenVG
09:49:18.270703 [notice] 2381 OSD - EGL_KHR_image EGL_KHR_image_base EGL_KHR_image_pixmap EGL_KHR_vg_parent_image EGL_KHR_gl_texture_2D
09:49:18.272331 [notice] 2381 OSD - _image EGL_KHR_gl_texture_cubemap_image EGL_KHR_lock_surface
09:49:18.276104 [WARN] 2381 OSD - Getting display size failed! (BCM API)
09:49:18.277776 [EMERG] 2381 Core - OSD module failed to initialise
09:49:18.279390 [notice] 2381 Core - BoxStack module shut down
09:49:18.280978 [notice] 2381 Core - Command module shut down
09:49:18.282750 [notice] 2381 Core - VDR module shut down
09:49:18.285033 [notice] 2381 Core - OSD module shut down
09:49:18.286634 [notice] 2381 Core - Audio module shut down
09:49:18.288335 [notice] 2381 Video - Shutdown video module
09:49:18.290006 [debug] 2381 Video - enter deallocatecodecsomx
09:49:18.291592 [debug] 2381 Video - leave deallocate codecs OMX
09:49:18.305092 [notice] 2381 Core - Video module shut down
09:49:18.307196 [debug] 2381 Timers - Timers shutdown start
09:49:18.310475 [debug] 2381 Timers - Timers shutdown end
09:49:18.312801 [notice] 2381 Core - Timers module shut down
09:49:18.315819 [notice] 2381 Core - MTD module shut down
09:49:18.317855 [notice] 2381 Core - LED module shut down
09:49:18.319847 [debug] 2381 Remote - CECLOG: 1480 16 marking Recorder 1 (1) as inactive source
09:49:18.321752 [debug] 2381 Remote - CECLOG: 1482 4 >> source deactivated: Recorder 1 (1)
09:49:18.324780 [debug] 2381 Remote - CECLOG: 1485 4 << Recorder 1 (1) -> broadcast (F): inactive source
09:49:18.326707 [debug] 2381 Remote - CECLOG: 1487 8 << 10:9d:10:00
09:49:18.328816 [debug] 2381 Remote - CECLOG: 1489 16 sending data: len = 3, payload = 10:9D:10:00
09:49:18.481347 [debug] 2381 Remote - CECLOG: 1642 16 received data: header:00040001 p0:00109D10 p1:00000000 p2:00000000 p3:00000000 reason:1
09:49:18.481992 [debug] 2381 Remote - CECLOG: 1642 16 received data: header:00030002 p0:00028D01 p1:00000000 p2:00000000 p3:00000000 reason:2
09:49:18.483521 [debug] 2381 Remote - CECLOG: 1644 8 >> 01:8d:02
09:49:18.485554 [debug] 2381 Remote - CECLOG: 1646 4 >> TV (0) -> Recorder 1 (1): menu request (8D)
09:49:18.488201 [debug] 2381 Remote - CECLOG: 1649 4 << Recorder 1 (1) -> TV (0): menu state 'activated'
09:49:18.489990 [debug] 2381 Remote - CECLOG: 1650 8 << 10:8e:00
09:49:18.492076 [debug] 2381 Remote - CECLOG: 1652 16 sending data: len = 2, payload = 10:8E:00
09:49:18.495460 [debug] 2381 Remote - CECLOG: 1652 16 command transmitted
09:49:18.497201 [debug] 2381 Remote - CECLOG: 1658 4 unregistering all CEC clients
09:49:18.499084 [debug] 2381 Remote - CECLOG: 1659 4 unregistering client: libCEC version = 1.9.0, client version = 1.9.0, firmware version = 1, log
09:49:18.501628 [debug] 2381 Remote - CECLOG: 1662 16 Recorder 1 (1): power status changed from 'on' to 'unknown'
09:49:18.504176 [debug] 2381 Remote - CECLOG: 1665 16 Recorder 1 (1): CEC version unknown
09:49:18.505876 [debug] 2381 Remote - CECLOG: 1666 16 Recorder 1 (1): osd name set to 'Recorder 1'
09:49:18.507723 [debug] 2381 Remote - CECLOG: 1668 16 Recorder 1 (1): device status changed into 'unknown'
09:49:18.509403 [debug] 2381 Remote - CECLOG: 1670 4 unregistering all CEC clients
09:49:18.638223 [debug] 2381 Remote - CECLOG: 1799 16 received data: header:00030001 p0:00008E10 p1:00000000 p2:00000000 p3:00000000 reason:1
09:49:18.639072 [debug] 2381 Remote - CECLOG: 1799 16 received data: header:00030002 p0:00011A01 p1:00000000 p2:00000000 p3:00000000 reason:2
09:49:18.640455 [debug] 2381 Remote - CECLOG: 1801 16 command transmitted
09:49:18.642793 [debug] 2381 Remote - CECLOG: 1803 16 UnregisterLogicalAddress - releasing previous logical address
09:49:18.848270 [debug] 2381 Remote - CECLOG: 2009 16 received data: header:00030001 p0:00008E10 p1:00000000 p2:00000000 p3:00000000 reason:1
Segmentation fault
Claus
It does not find a video mode, since it did not communicate with the display.
No display is turned on, so the initialisation failed.
So please turn on a display before.
E.g. with tvservice -p .
The question is why are no cea modes present, play around with tvservice.
Marten
Hi,
the TV is on and shows before the first start of the vompclinet the console. At the start of the vompclinet it shows for a short time a black (vompclinet) screen and switch than back to the default input (in my case the analog TV).
I will try what tvservice says today evening.
Claus
I thought about this.
What do you mean with default input?
Do you set the analog output in config.txt?
Then there is nothing I can do about this.
Since setting a mode in config text does the following:
it removes all other supported modes from being reported by the firmware!
That means I can not switch to any other mode than the one set in config.txt with vomp !
So there is nothing I can do about this.
If you want analog input switched on at startup, execute a skript right in the startup sequence, that uses tvservice to power off or power on the mode you want.
Marten
Hi Marten,
you do not understand me right. I have not selected analog output on the RPI. Only my TV switch to the analog source, if no other source is available (or if the vompclinet do a seg fault). So I use only the hdmi output of the RPI and have not set up any modes in the config.txt
Claus
PS.: until now, I have not found the time, to make the tests with the tvservice tool. I hope I can do it today evening
Anyway I just commited some changes on this part of the code, so please try the new version.
Marten
Hi,
it's hard to understand what's happens. Today the vompclient starts up. OK, not on the first try, but on the third !?! I try this servers times. After every reboot, the vompclient does two seg faults, and starts on the third try.
After I update to the latest version, it don't want to start any more, like on Friday. I try to set a special mode by the tvservice tool, but this don't helps.
Claus
PS.: I fond the reason, why I don't see the boot screen on reboot. The reason was, that I disabled the hdmi cec init in the config.txt file. I did so, because I don't want the switch to the RPI on bootup if I watch TV on a other source of the TV.
Ok, need logs and please also post all modes and other stuff reported by the tvservice tool.
Btw, I suspect, that new code is switching to analog output.
Since if no information about an hdmi connection is present vomp switches to analog output now.
Anyway, I recommend to not disable cec at startup.
Marten
Please test current git.
Anyway even if it works at first sight, I would like to see a log.
I am not sure if selection of CEA modes work in your setup.
Marten
Hi,
now the new version starts without problems. Anyway, I will post the requested logfile later.
Here I have the tvservice info for you:
MLD> tvservice -s
state: HPD high|HDMI mode|composite off (0x12000a), 1920x1080 @ 50Hz, progressive
MLD> tvservice -m CEA
Group CEA has 14 modes:
mode 1: 640x480 @ 60Hz, progressive
mode 2: 720x480 @ 60Hz, progressive
mode 3: 720x480 @ 60Hz, progressive
mode 4: 1280x720 @ 60Hz, progressive
mode 5: 1920x1080 @ 60Hz, interlaced
(native) mode 16: 1920x1080 @ 60Hz, progressive
mode 17: 720x576 @ 50Hz, progressive
mode 18: 720x576 @ 50Hz, progressive
mode 19: 1280x720 @ 50Hz, progressive
mode 20: 1920x1080 @ 50Hz, interlaced
mode 31: 1920x1080 @ 50Hz, progressive
mode 32: 1920x1080 @ 24Hz, progressive
mode 33: 1920x1080 @ 25Hz, progressive
mode 34: 1920x1080 @ 30Hz, progressive
MLD> tvservice -a
PCM supported: Max channels: 2, Max samplerate: 48kHz, Max samplesize 24 bits.
Claus
So, now I have two logfiles for you.
The first one I get if the TV disconnect from the vompclient "no signal" (every second to third start). But the vompclient runs without error messages. In this kind tvservice says this:
MLD> tvservice -s
state: HPD high|HDMI mode|HDCP off|composite off (0x12001a), 1920x1080 @ 50Hz, progressive
The second one I get if the start is OK and I see the vompclinet start screen:
MLD> tvservice -s
state: HPD high|HDMI mode|composite off (0x12000a), 1920x1080 @ 50Hz, progressive
Claus
Thanks, but you misunderstood me. I wanted log files with the new code.
Even if it looks fine too you, it is possible, that vomp uses some fall back code, since it is likely that no CEA modes are available.
In this case I might add a second hdmi power on command before querying the cea modes, that is for getting the best availiable mode.
Marten
Hi,
I took the log files with the latest vompclient version (the version of the 08.11.2012).
After every reboot, the vompclient starts the first one without problems. Mostly after a restart of the vompclient, the TV lost the connection and shows "no signal",...
Claus
QuoteMostly after a restart of the vompclient
What does a restart mean, really restating the executable or using the power key to turn off the display?
Or did you kill it? (Then anything can happen)
QuoteMostly after a restart of the vompclient, the TV lost the connection and shows "no signal",...
This is because, the firmware says no hdmi cable connected so we are falling back to analog.
Please try to add in the beginning of VideoOMX::selectVideoMode to add
vc_tv_hdmi_power_on_preferred();This will first power on hdmi, before doing anything else.
May be you have to add a
MILLISLEEP(100);after it. (Play with the 100).
Marten
Hi,
with restart I mean to kill and start the vompclient.
I will try your suggestions tomorrow.
Does you power off the hdmi if I kill the vompclient? It seems so, because if I kill it, the TV switched to an other source. If I start the vompclient, the TV switch to the vompclinet hdmi source, but if it fails (about every second try), it switched back to an other source after one second.
On all this tests I only start the vompclient, and do not select a TV channel. Also I have no seg fault with this vompclinet version.
Claus
Quotewith restart I mean to kill and start the vompclient.
What kind of kill with signal 9 or so that it can exit gently.
On clean exit the frame buffer device is restored, may be this causes some problems with your hdmi set.
Also libcec is torn down, probably also powering off your tv??
Marten
Yes, I made a "kill -9" since a SIGTERM do not kill the vompclient in most cases. OK, I try the SIGTERM some weeks ago at last. I will check if a SIGTERM will be better.
Claus
Well, if you use -9, then it clear that it can not work, because the routines for restoring the raspberry state are not called.
SIGTERM should always work, if not it is a bug, which has to be fixed.
Marten
Hi,
OK, now I have made some tests. The kill SIGTERM works. But it makes no different to a kill -9.
I have add your changes and detect, that it helps with a millisleep of 3000 (2000 is to less). If I take a look on the "tvservice -m CEA" output until I start the vompclient, I see, that for about 0.2 Seconds no modes avaliable. In the case, that the start get well, there are two times 0.2 Seconds (with a distance of 0.5 Seconds) no modes available. So I think, it is necessary, to test for some Seconds, if there will be modes available. Or better, if you can found the reason why this filed (now exact) every second try, to fix it if it's possible.
Also I have a other with. If I stop the vompclient, my TV switched to a other input source. If I than switch the TV beck to the hdmi source, I can see the terminal. Is it possible, to let the hdmi source activated on vompclient stop, so that the TV don't switch to an other source?
Claus
QuoteI have add your changes and detect, that it helps with a millisleep of 3000 (2000 is to less).
Ok, then forget about the changes, 2-3 seconds is too long.
I have another idea, go to remotelinux.cc and comment the line:
cec_adap->SetInactiveView();Tell me what is happening then, maybe changing the cec stuff will help in the end. (This is not a solution but something, that helps me to get anidea waht is happening.)
Marten
OK, this helps. Now the vompclient starts every time correct.
Also the TV do not switch to an other source on vompclinet stop.
Claus
@clausmuus
I did not have time to lock into this, this weekend.
Maybe next, I had a very difficult bug to find, connected with signal off and on.
Try the git maybe it is solved by accident, but I do not believe so.
Marten
Hi Marten,
that's no problem, since I give back my borrowed RPI today and not get already my own. I think I will get my own one this or next week. But until next week I will be in vacation for two week, so now you have three weeks to find a solution :)
Claus