Enigma restarts after display of png

[stevebow]

I have attached a 1920x1080 8-bit/greyscale png that I knocked up in Photoshop. It will display fine in the Media Player for a few seconds, then an on-screen crash log is displayed and Enigma is restarted. My T4 is on the production 20180417 f/w.

Can anyone else reproduce this?

Here is the serial log from pressing OK to display the image (which displays) until the on-screen log appears:

Code: Select all

=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2018.10.24 15:52:39 =~=~=~=~=~=~=~=~=~=~=~=
{3824}<  4948.702> KEY: 352 make KEY_OK ('OK',)
{3824}<  4948.702> [ActionMap] OkCancelActions ok
{3824}<  4948.731> [fb] double buffering available!
{3824}<  4948.764> [gFBDC] resolution: 1920x1080x32 stride=7680, 8100kB available for acceleration surfaces.
{3824}<  4948.768> [Skin] Parsing embedded skin <embedded-in-'Pic_Full_View'>
{3824}<  4948.769> [Skin] processing screen <embedded-in-'Pic_Full_View'>:
{3824}[video_videomodepreferred_read] mode(0) not found!!!
{5244}<  4948.883> [EXIF] getting exif from JPEG
{3824}<  4948.888> [Skin] processing screen SimpleSummary:
{3824}<  4948.970> [SCREENNAME]  ['Pic_Full_View_summary', 'SimpleSummary']
{3824}<  4948.975> [SCREENNAME]  Pic_Full_View
{3824}<  4948.979> KEY: 352 break KEY_OK ('OK',)
{5244}<  4949.048> [EXIF] getting exif from JPEG
{3824}<  4949.089> PC: 00575f14
{3824}<  4949.089>     00000000 00000001 7fafa750 00000000
{3824}<  4949.089>     00000000 00000000 7fafa720 00000000
{3824}<  4949.089>     00000000 00000001 6eaf7008 000001e0
{3824}<  4949.089>     0000001f ffffffff 01230828 00770000
{3824}<  4949.089>     012b6538 00000001 75ca4000 00000000
{3824}<  4949.089>     012307d8 00000438 000005a0 000000f0
{3824}<  4949.089>     00776808 767dd820 ffffffff 00000000
{3824}<  4949.089>     76805020 7fafa700 00000000 00575f04
{3824}<  4949.090> Backtrace:
{3824}<  4949.090> /usr/bin/enigma2(_Z17handleFatalSignaliP9siginfo_tPv) [0x45aef8]
{3824}<  4949.091> /usr/bin/enigma2(_ZN8ePicLoad7getDataER4ePtrI7gPixmapE) [0x575f16]
{3824}<  4949.091> /usr/bin/enigma2(n/a) [0x5ed590]
{3824}<  4949.092> /usr/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx) [0x76e3c12c]
{3824}<  4949.092> -------FATAL SIGNAL (11)
{3826}<  4953.146> [gRC] main thread is non-idle! display spinner!
/usr/bin/enigma2.sh: line 77:  3824 Killed                  LD_PRELOAD=$LIBS ${bindir}/enigma2

[Grumpy_Geoff]

U4 on 20181003 beta: image doesn't display, just a UI crash -

Code: Select all

{8030}< 12472.214> KEY: 352 make KEY_OK ('OK',)
{8030}< 12472.214> [ActionMap] OkCancelActions ok
{8030}< 12472.220> [Skin] Parsing embedded skin <embedded-in-'Pic_Full_View'>
{8030}< 12472.220> [Skin] processing screen <embedded-in-'Pic_Full_View'>:
{8255}< 12472.232> [EXIF] getting exif from JPEG
{8030}< 12472.233> [Skin] processing screen SimpleSummary:
{8030}< 12472.234> [SCREENNAME]  ['Pic_Full_View_summary', 'SimpleSummary']
{8030}< 12472.235> [SCREENNAME]  Pic_Full_View
{8030}< 12472.249> Backtrace:
{8030}< 12472.250> /usr/bin/enigma2(_Z17handleFatalSignaliP9siginfo_tPv) [0x6e084]
{8030}< 12472.250> /lib/libc.so.6(__default_rt_sa_restorer) [0xb61c0c60]
{8030}< 12472.250> /usr/bin/enigma2(_ZN8ePicLoad7getDataER4ePtrI7gPixmapE) [0x176d00]
{8030}< 12472.250> /usr/bin/enigma2(n/a) [0x1e4d7c]
{8030}< 12472.250> -------FATAL SIGNAL (11)

[MrQuade]

Does it appear to happen with any PNG, or just select ones like the one attached?
Does the file location matter?
Have you noticed it with any other image formats?

Interesting that the log is talking about JPEG EXIF metadata (which PNG doesn't have). I wonder if it is a sign of a problem or is the software just being sloppy with its logging.

[Grumpy_Geoff]

Another PNG from same location is fine -

Code: Select all

{9207}< 13807.408> KEY: 352 make KEY_OK ('OK',)
{9207}< 13807.409> [ActionMap] OkCancelActions ok
{9207}< 13807.416> [Skin] Parsing embedded skin <embedded-in-'Pic_Full_View'>
{9207}< 13807.417> [Skin] processing screen <embedded-in-'Pic_Full_View'>:
{9480}< 13807.429> [EXIF] getting exif from JPEG
{9207}< 13807.430> [Skin] processing screen SimpleSummary:
{9207}< 13807.432> [SCREENNAME]  ['Pic_Full_View_summary', 'SimpleSummary']
{9207}< 13807.432> [SCREENNAME]  Pic_Full_View
{9207}< 13807.435> KEY: 352 break KEY_OK ('OK',)
{9480}< 13807.532> [EXIF] getting exif from JPEG
{9207}< 13808.463> [eConsoleAppContainer] Starting /usr/bin/grab
{9480}< 13812.432> [EXIF] getting exif from JPEG

A JPG displays fine too.

[Paul_oz53]

Does it appear to happen with any PNG, or just select ones like the one attached?
Does the file location matter?
Have you noticed it with any other image formats?

Interesting that the log is talking about JPEG EXIF metadata (which PNG doesn't have). I wonder if it is a sign of a problem or is the software just being sloppy with its logging.

I know it doesn't happen with jpg/jpeg on the U4 20181003 or the T4 on 2018092x. They play fine, having looked at a few hundred over the weekend trying to find a particular happy snap.

[prl]

I get the same on a T4 when I try to display the HD Outline + 4x3 box.png image in the media player (MEDIA from live TV) or in the Photo Viewer (MENU>Photos from live TV).

The key to the problem seems to be: {5244}< 4948.883> [EXIF] getting exif from JPEG. The file isn't JPEG, it's PNG.

There is a test in Cexif::DecodeExifJpeg() that checks whether the file is in fact JPEG and returns false if it is not, but a higher-level caller ignores the error return and goes ahead assuming that the EXIF data has been read, even when it hasn't.

The cause is:

Code: Select all

class Cexif
{
public:
	...
	bool DecodeExif(const char *filename, int Thumb=0, int fileType=F_JPEG);

combined with the only call of Cexif::DecodeExif() in the code:

Code: Select all

		return m_exif->DecodeExif(filename, Thumb);

So the lower level code is told that the file is JPEG, whether it is or not, and the error return is ignored if the upper level is telling lies. The EXIF data encodes image metadata, including things that are rather useful to image display, like the pixmap width, height and depth.

I also looked at a copy of /usr/share/enigma2/rc_models/ini5/rc.png in both the Picture Viewer and media player (both use the same Screen class to display images). It doesn't crash the UI, but the actual image display is a complete mess.

Lessons:

• Don't assume that default parameters are correct.
• Don't ignore error return values.

[MrQuade]

The working example from Grumpy Geoff shows the same test, and that one doesn't crash, so I wonder what the difference is.

[prl]

The working example from Grumpy Geoff shows the same test, and that one doesn't crash, so I wonder what the difference is.

In my post I mentioned that a copy of /usr/share/enigma2/rc_models/ini5/rc.png didn't crash when viewed, though its image was a mess.

I suspect what happens depends on what junk ends up in the objects that are supposed to be being initialised from the EXIF data.

[adoxa]

Does it appear to happen with any PNG, or just select ones like the one attached?

I think it's because it's 8-bit greyscale. The crash occurs when it reads the background from the palette, only there is no palette.

Code: Select all

// lib/gdi/picload.cpp:1032
			if (bg != surface->clut.data[background] && surface->clut.colors < 256) {

That should first test background < surface->clut.colors and/or surface->clut.data != NULL.

Interesting that the log is talking about JPEG EXIF metadata (which PNG doesn't have). I wonder if it is a sign of a problem or is the software just being sloppy with its logging.

Doubly sloppy: DecodeExifJpeg logs entry, then does the check for a JPEG (the image info says it's not a JPEG); and prl's already pointed out the problem with the wrong type.

[prl]

That's consistent with the image that I tried and didn't crash:

Code: Select all

Cambyses:enigma2 prl$ file branding-module/BoxBranding/remotes/ini5/rc.png 
branding-module/BoxBranding/remotes/ini5/rc.png: PNG image data, 112 x 500, 8-bit/color RGBA, interlaced
Cambyses:enigma2 prl$

No colourmap there.

[prl]

Viewing one of the front panel channel picons (which is PNG greyscale) results in the crash.

[adoxa]

Here's a potential fix:

Code: Select all

diff --git a/lib/gdi/picload.cpp b/lib/gdi/picload.cpp
index a510f4326..a05dd0623 100644
--- a/lib/gdi/picload.cpp
+++ b/lib/gdi/picload.cpp
@@ -937,7 +937,7 @@ bool ePicLoad::getExif(const char *filename, int Thumb)
 {
 	if (!m_exif) {
 		m_exif = new Cexif;
-		return m_exif->DecodeExif(filename, Thumb);
+		return m_exif->DecodeExif(filename, Thumb, m_filepara ? m_filepara->id : getFileType(filename));
 	}
 	return true;
 }
@@ -1029,7 +1029,7 @@ int ePicLoad::getData(ePtr<gPixmap> &result)
 		gRGB bg(m_conf.background);
 		if (m_filepara->bits == 8) {
 			background = surface->clut.findColor(bg);
-			if (bg != surface->clut.data[background] && surface->clut.colors < 256) {
+			if (surface->clut.data && bg != surface->clut.data[background] && surface->clut.colors < 256) {
 				gRGB* newClut = new gRGB[surface->clut.colors + 1];
 				for (int c = 0; c < surface->clut.colors; c++) {
 					newClut[c] = surface->clut.data[c];

I notice that OpenPLi/OpenViX have different code, but I didn't check if it was newer or older.

[prl]

The fix looks good to me.

[IanSav]

Hi,

Just for giggles I tested the image in the first post on my current OpenViX box and the image displays fine. No issues, no crash.

Regards,
Ian.

[prl]

Thanks. I was going to try that today.

[adoxa]

Having another look at the code in OpenVix, it turns out this is actually prl's code from Nov '16. It was merged into OpenViX in Feb this year, then reverted. They also fixed the EXIF file type issue about then, too (from an earlier commit on Nov '15).

[stevebow]

Yes, as has been discussed, it is greyscale pngs that cause the crash.

Thanks everyone for your replies, and adoxa for the quick fix.