Jump to content


Photo

Enigma2 severe(blocker) bug caused by use off eDebug


  • Please log in to reply
128 replies to this topic

Re: Enigma2 severe(blocker) bug caused by use off eDebug #21 littlesat

  • PLi® Core member
  • 56,123 posts

+685
Excellent

Posted 6 February 2016 - 18:20

Why not simply change the debugLv1 while E2 is running..... and with reboot get back to default or EMIGMA_DEBUG_LVL....


WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: Enigma2 severe(blocker) bug caused by use off eDebug #22 christophecvr

  • Senior Member
  • 3,131 posts

+140
Excellent

Posted 6 February 2016 - 18:23

Hi christophecvr,

Is there a reason that eConfigManager::getConfigIntValue not working and you implement getConfigString?

Also why not a simpler version to get debugLvl?
 

-	debugLvl = getenv("ENIGMA_DEBUG_LVL") ? atoi(getenv("ENIGMA_DEBUG_LVL")) : 4;
+	debugLvl = getenv("ENIGMA_DEBUG_LVL") ? atoi(getenv("ENIGMA_DEBUG_LVL")) : eConfigManager::getConfigIntValue("config.usage.e2_debug_level", 4);

Yes the eConfigManager is part from python enigma(is a python class instance). The debug level (out off configs) must be obtained before enigma2(python) starts.

 

Simplification perhaps a very little improvement can be done by changing lines :

	// get enigma2 debug level
	if (getenv("ENIGMA_DEBUG_LVL"))
		debugLvl = getenv("ENIGMA_DEBUG_LVL") ? atoi(getenv("ENIGMA_DEBUG_LVL")) : 4;
	else
		debugLvl = atoi(getConfigString("config.usage.e2_debug_level", "4").c_str());

To

		// get enigma2 debug level
		debugLvl = getenv("ENIGMA_DEBUG_LVL") ? atoi(getenv("ENIGMA_DEBUG_LVL")) : atoi(getConfigString("config.usage.e2_debug_level", "4").c_str());

Should work also but I did not test it yet.



Re: Enigma2 severe(blocker) bug caused by use off eDebug #23 christophecvr

  • Senior Member
  • 3,131 posts

+140
Excellent

Posted 6 February 2016 - 18:30

Why not simply change the debugLv1 while E2 is running..... and with reboot get back to default or EMIGMA_DEBUG_LVL....

Now the debug is a pretty intensive issue . If You For example would add be eerror.cpp concerned routines countunousely polling off the eConfigManager::getConfigIntValue("config.usage.e2_debug_level") This will be executed tremendously en does cause segfaults and or full freezes at the end.



Re: Enigma2 severe(blocker) bug caused by use off eDebug #24 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 6 February 2016 - 18:34

Why not simply change the debugLv1 while E2 is running..... and with reboot get back to default or EMIGMA_DEBUG_LVL....

Now the debug is a pretty intensive issue . If You For example would add be eerror.cpp concerned routines countunousely polling off the eConfigManager::getConfigIntValue("config.usage.e2_debug_level") This will be executed tremendously en does cause segfaults and or full freezes at the end.


Actually leave the default 4 and change the debug level from menu afterwards, without pooling configManager.
Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: Enigma2 severe(blocker) bug caused by use off eDebug #25 christophecvr

  • Senior Member
  • 3,131 posts

+140
Excellent

Posted 6 February 2016 - 18:47

But if what is very useful to this parameter. (obvious further adaptations are needed )

 

are  :

 

1) For now the default is still for (in future it should become 0 for standard user)

2) If A standard more rookie user has a problem. That in some circumstances a crash occurs. A dev can still ask to the user to set his debug level to a certain level (x). Trough interface.

     Tell him to restart the box and replay the media or xxx which leaded to the crash and so obtain a crash log with more details.

3) Not implemented!! Yet but that's more for testers and developpers. I can add in for example (the one I now much and on which i'm working now) servicemp3.cpp

 

By the start player fase.

if (!getenv("ENIGMA_DEBUG_LVL"))
    debugLvl = eConfigManager::getConfigIntValue("config.usage.e2_debug_level");

So if You did not run with a forced EMIGMA_DEBUG_LVL=<x>  but just with enigma2.sh in console. (And so work with the standard debug level which you had at start)

 

Found a problem while playing a certain file which uses the servicemp3.cpp player. Stop the playing (normaly like a standard user with remote ) Then go to the menu and ... change the debug level . restart the media You played and You will heve a higher debug level.



Re: Enigma2 severe(blocker) bug caused by use off eDebug #26 christophecvr

  • Senior Member
  • 3,131 posts

+140
Excellent

Posted 6 February 2016 - 19:49

Here the patch now ready to push with the simplification in code (thanks to athoik)

 

lines :

	// get enigma2 debug level
	if (getenv("ENIGMA_DEBUG_LVL"))
		debugLvl = getenv("ENIGMA_DEBUG_LVL") ? atoi(getenv("ENIGMA_DEBUG_LVL")) : 4;
	else
		debugLvl = atoi(getConfigString("config.usage.e2_debug_level", "4").c_str());

are adapted to (it's tested on duo2 and dm8000)

		// get enigma2 debug level
		debugLvl = getenv("ENIGMA_DEBUG_LVL") ? atoi(getenv("ENIGMA_DEBUG_LVL")) : atoi(getConfigString("config.usage.e2_debug_level", "4").c_str());

(and also a typo whit trailing white space in previous patch is removed removed)

 

 

Attached Files



Re: Enigma2 severe(blocker) bug caused by use off eDebug #27 christophecvr

  • Senior Member
  • 3,131 posts

+140
Excellent

Posted 7 February 2016 - 08:07

Here another small modified version off previous patch.

 

I'm using now the std::string.compare function off cplus instead off the c strncmp.

 

I noticed also an error into main/bsod.cpp: the function below will never work.

static const std::string getConfigString(const std::string &key, const std::string &defaultValue)
{
	std::string value = eConfigManager::getConfigValue(key.c_str());

	//we get at least the default value if python is still alive
	if (!value.empty())
		return value;

	value = defaultValue;

	// get value from enigma2 settings file
	std::ifstream in(eEnv::resolve("${sysconfdir}/enigma2/settings").c_str());
	if (in.good()) {
		do {
			std::string line;
			std::getline(in, line);
			size_t size = key.size();
			if (!key.compare(0, size, line) && line[size] == '=') {
				value = line.substr(size + 1);
				break;
			}
		} while (in.good());
		in.close();
	}

	return value;
}

This cause the line 97 std::string.compare is wrong.

 

It should be :

static const std::string getConfigString(const std::string &key, const std::string &defaultValue)
{
	std::string value = eConfigManager::getConfigValue(key.c_str());

	//we get at least the default value if python is still alive
	if (!value.empty())
		return value;

	value = defaultValue;

	// get value from enigma2 settings file
	std::ifstream in(eEnv::resolve("${sysconfdir}/enigma2/settings").c_str());
	if (in.good()) {
		do {
			std::string line;
			std::getline(in, line);
			size_t size = key.size();
			if (!line.compare(0, size, key) && line[size] == '=') {
				value = line.substr(size + 1);
				break;
			}
		} while (in.good());
		in.close();
	}

	return value;
}

If desired I'll also can make a patch for the bsod.cpp error.

 

 

Attached Files



Re: Enigma2 severe(blocker) bug caused by use off eDebug #28 christophecvr

  • Senior Member
  • 3,131 posts

+140
Excellent

Posted 7 February 2016 - 08:21

Oeps also forgot in patch to reset the hard targetting to sysconfdir from /etc to ${sysconfdir}

 

Here the corrected patch

 

 

Attached Files



Re: Enigma2 severe(blocker) bug caused by use off eDebug #29 littlesat

  • PLi® Core member
  • 56,123 posts

+685
Excellent

Posted 7 February 2016 - 10:36

New you're reading all configs twice.... This is not done and too complicated

I would recommend to add a function in cpp that is capable of changing the debug level by calling it via swig or so from python... Simplify it in the code now that it uses 4... When the config is read in normal code it calls this function an set it as configured, except when the env variable is set (this overrules)...

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: Enigma2 severe(blocker) bug caused by use off eDebug #30 christophecvr

  • Senior Member
  • 3,131 posts

+140
Excellent

Posted 7 February 2016 - 11:03

New you're reading all configs twice.... This is not done and too complicated

I would recommend to add a function in cpp that is capable of changing the debug level by calling it via swig or so from python... Simplify it in the code now that it uses 4... When the config is read in normal code it calls this function an set it as configured, except when the env variable is set (this overrules)...

Sorry I can't follow what You mean.

 

I do not read settings twice .

 

Gues You're a little confused between bsod.cpp and enigma.cpp

 

First let's look a the start sequence .

 

1) Start off enigma2 execution off enigma2.cpp which will init all needed stuff.

2) See the main execution order :

int main(int argc, char **argv)
{
#ifdef MEMLEAK_CHECK
	atexit(DumpUnfreed);
#endif

#ifdef OBJECT_DEBUG
	atexit(object_dump);
#endif

	gst_init(&argc, &argv);

	// set pythonpath if unset
	setenv("PYTHONPATH", eEnv::resolve("${libdir}/enigma2/python").c_str(), 0);
	printf("PYTHONPATH: %s\n", getenv("PYTHONPATH"));
	printf("DVB_API_VERSION %d DVB_API_VERSION_MINOR %d\n", DVB_API_VERSION, DVB_API_VERSION_MINOR);

	// get enigma2 debug level
	debugLvl = getenv("ENIGMA_DEBUG_LVL") ? atoi(getenv("ENIGMA_DEBUG_LVL")) : atoi(getConfigString("config.usage.e2_debug_level", "4").c_str());

	if (debugLvl < 0)
		debugLvl = 0;
	debugTag = getenv("ENIGMA_DEBUG_TAG");
	printf("ENIGMA2_DEBUG settings: Level=%d, Tag=%s\n", debugLvl, debugTag ? debugTag : "");

	bsodLogInit();

	ePython python;
	eMain main;

De debug setting must be known before start off bsodLogInit and the bsodLogInit  must be done before ePython python and the eMain main must be done after python start.

 

The python class eConfigureManager::<xxxx> is only avbl after that python and I gues even eMain main is done.

 

But the dbg level setiing must be know before. So No there is No double excecution.



Re: Enigma2 severe(blocker) bug caused by use off eDebug #31 MiLo

  • PLi® Core member
  • 14,042 posts

+298
Excellent

Posted 7 February 2016 - 11:06

The debug level can be set any time by just changing the value of "debugLvl".
Real musicians never die - they just decompose

Re: Enigma2 severe(blocker) bug caused by use off eDebug #32 christophecvr

  • Senior Member
  • 3,131 posts

+140
Excellent

Posted 7 February 2016 - 11:21

The debug level can be set any time by just changing the value of "debugLvl".

That's trough however You need that value from out off configs Before the log is initited and also it's supposed to be set before python start.

 

What well can be said into the bsod.cpp  (log file application) There also they needed to add a separate function getConfigString cause python is not running yet . And they need (apparently to know the skin setting).

 

If it is required into bsod.cpp ?? well i'm not so shure , (but that's not from me) I even think it is not required att all unless ... But anyway how it is set there it does not work due to error in compare function.

Why it's there ? do not ask me I did not do that. And it even does not work.

 

Not ok due to line 87 (cplus compare function) in bsod.cpp is :

static const std::string getConfigString(const std::string &key, const std::string &defaultValue)
{
	std::string value = eConfigManager::getConfigValue(key.c_str());

	//we get at least the default value if python is still alive
	if (!value.empty())
		return value;

	value = defaultValue;

	// get value from enigma2 settings file
	std::ifstream in(eEnv::resolve("${sysconfdir}/enigma2/settings").c_str());
	if (in.good()) {
		do {
			std::string line;
			std::getline(in, line);
			size_t size = key.size();
			if (!key.compare(0, size, line) && line[size] == '=') {
				value = line.substr(size + 1);
				break;
			}
		} while (in.good());
		in.close();
	}

	return value;
}

This means that :

		xml.string("skin", getConfigString("config.skin.primary_skin", "Default Skin"));

Will never work.

 

And the :

	std::string value = eConfigManager::getConfigValue(key.c_str());

	//we get at least the default value if python is still alive
	if (!value.empty())
		return value;

Is also useless in bsod.cpp


Edited by christophecvr, 7 February 2016 - 11:23.


Re: Enigma2 severe(blocker) bug caused by use off eDebug #33 littlesat

  • PLi® Core member
  • 56,123 posts

+685
Excellent

Posted 7 February 2016 - 11:40

Nope.... at the moment you read the config in python you can change that level in an appropriate way... You do not read the configs twice...


Edited by littlesat, 7 February 2016 - 11:43.

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: Enigma2 severe(blocker) bug caused by use off eDebug #34 christophecvr

  • Senior Member
  • 3,131 posts

+140
Excellent

Posted 7 February 2016 - 11:47

Nope.... at the moment you read the config in python you can change that level in an appropriate way... You do not read the configs twice...

explain ???


Edited by christophecvr, 7 February 2016 - 11:48.


Re: Enigma2 severe(blocker) bug caused by use off eDebug #35 littlesat

  • PLi® Core member
  • 56,123 posts

+685
Excellent

Posted 7 February 2016 - 12:47

Simply change some cpp-code so you have a function that you can call from python to change the level code....

 

As soon you handle the configs in python you change the level code appropriate...

 

And I agree the bsod does also read the settings file... but only when it is not readed yet... and only to get the basic skin in the config (and also in fact an ugly hack).... But at least here the settings file is read once....


Edited by littlesat, 7 February 2016 - 12:53.

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: Enigma2 severe(blocker) bug caused by use off eDebug #36 mirakels

  • Forum Moderator
    PLi® Core member
  • 7,598 posts

+62
Good

Posted 7 February 2016 - 13:01

Here another small modified version off previous patch.

 

I'm using now the std::string.compare function off cplus instead off the c strncmp.

 

I noticed also an error into main/bsod.cpp: the function below will never work.

static const std::string getConfigString(const std::string &key, const std::string &defaultValue)
{
	std::string value = eConfigManager::getConfigValue(key.c_str());

	//we get at least the default value if python is still alive
	if (!value.empty())
		return value;

	value = defaultValue;

	// get value from enigma2 settings file
	std::ifstream in(eEnv::resolve("${sysconfdir}/enigma2/settings").c_str());
	if (in.good()) {
		do {
			std::string line;
			std::getline(in, line);
			size_t size = key.size();
			if (!key.compare(0, size, line) && line[size] == '=') {
				value = line.substr(size + 1);
				break;
			}
		} while (in.good());
		in.close();
	}

	return value;
}

This cause the line 97 std::string.compare is wrong.

 

It should be :

static const std::string getConfigString(const std::string &key, const std::string &defaultValue)
{
	std::string value = eConfigManager::getConfigValue(key.c_str());

	//we get at least the default value if python is still alive
	if (!value.empty())
		return value;

	value = defaultValue;

	// get value from enigma2 settings file
	std::ifstream in(eEnv::resolve("${sysconfdir}/enigma2/settings").c_str());
	if (in.good()) {
		do {
			std::string line;
			std::getline(in, line);
			size_t size = key.size();
			if (!line.compare(0, size, key) && line[size] == '=') {
				value = line.substr(size + 1);
				break;
			}
		} while (in.good());
		in.close();
	}

	return value;
}

If desired I'll also can make a patch for the bsod.cpp error.

 

Explain this using examples...


Geen wonder... Had slechts een dm7000, maar wel ook een rotor. eigenlijk al een tijdje ook een dm600 en dm7025. Maar nu kijkend met een et9000 en vuduo

Re: Enigma2 severe(blocker) bug caused by use off eDebug #37 littlesat

  • PLi® Core member
  • 56,123 posts

+685
Excellent

Posted 7 February 2016 - 13:06

Think about something that is done here

 

https://github.com/O...tboxservice.cpp

 

with e.g. 

 

void eListboxServiceContent::setSize(const eSize &size)

void eListboxServiceContent::setGetPiconNameFunc(ePyObject func)

void eListboxServiceContent::setIgnoreService( const eServiceReference &service )

void eListboxServiceContent::setItemHeight(int height)

 

This changes values in "cpp".... with a call from python...

 

And the think in bsod.cpp I understand... Key is requested and it should be within the line... so I think christopher is right here.... he found another "bug" what is in there for more than 20 years...

And why is it bsod, the screen is green... ;)

 

my ubuntu build enviroment is somehow not stable so I cannot test this cpp change.


Edited by littlesat, 7 February 2016 - 13:16.

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: Enigma2 severe(blocker) bug caused by use off eDebug #38 christophecvr

  • Senior Member
  • 3,131 posts

+140
Excellent

Posted 7 February 2016 - 13:44

 

Here another small modified version off previous patch.

 

I'm using now the std::string.compare function off cplus instead off the c strncmp.

 

I noticed also an error into main/bsod.cpp: the function below will never work.

static const std::string getConfigString(const std::string &key, const std::string &defaultValue)
{
	std::string value = eConfigManager::getConfigValue(key.c_str());

	//we get at least the default value if python is still alive
	if (!value.empty())
		return value;

	value = defaultValue;

	// get value from enigma2 settings file
	std::ifstream in(eEnv::resolve("${sysconfdir}/enigma2/settings").c_str());
	if (in.good()) {
		do {
			std::string line;
			std::getline(in, line);
			size_t size = key.size();
			if (!key.compare(0, size, line) && line[size] == '=') {
				value = line.substr(size + 1);
				break;
			}
		} while (in.good());
		in.close();
	}

	return value;
}

This cause the line 97 std::string.compare is wrong.

 

It should be :

static const std::string getConfigString(const std::string &key, const std::string &defaultValue)
{
	std::string value = eConfigManager::getConfigValue(key.c_str());

	//we get at least the default value if python is still alive
	if (!value.empty())
		return value;

	value = defaultValue;

	// get value from enigma2 settings file
	std::ifstream in(eEnv::resolve("${sysconfdir}/enigma2/settings").c_str());
	if (in.good()) {
		do {
			std::string line;
			std::getline(in, line);
			size_t size = key.size();
			if (!line.compare(0, size, key) && line[size] == '=') {
				value = line.substr(size + 1);
				break;
			}
		} while (in.good());
		in.close();
	}

	return value;
}

If desired I'll also can make a patch for the bsod.cpp error.

 

Explain this using examples...

 

 

 

First lets look at the key to the config. :

Then look at the line (really writen)

The key to the config input here is just a string and lets take the just now added (if the patch is aplied) "config.usage.e2_debug_level"

 

Then we can tell :

 

std::string str1 = "config.usage.e2_debug_level"  // (the key)

std::string str2 = &line;  (comming out off configs if the key "config.usage.e2_debug_level=<x>" is present in configs default value is not for this reason we also at a default to the final function).

 

In code as example :

#include <iostream>
#include <string>
#include <fstream>
#include <sstream>

int main()
{
    std::string key = "config.usage.e2_debug_level";
    std::string value;
    std::string line;
    
    std::ifstream in(eEnv::resolve("/etc/enigma2/settings").c_str()); //read out enigma2 setting file which has the lets say setting config.usage.e2_debug_level=1
    if (in.good()) {
		do {
			std::getline(in, line);
			size_t size = key.size();
			if (!key.compare(0, size, line) && line[size] == '=') {
				value = line.substr(size + 1);
				break;
			}
		} while (in.good());
		in.close();
	}
   printf("config value for key = %s", value.c_str());
}

Nothing will be printed (in despit the fact that key config.usage.e2_debug_level=1  is present in settings file).

 

That cause You compare

 

"config.usage.e2_debug_level"  with  "config.usage.e2_debug_level=1"

 

However same procedure but correct compare string in cplus:

#include <iostream>
#include <string>
#include <fstream>
#include <sstream>

int main()
{
    std::string key = "config.usage.e2_debug_level";
    std::string value;
    std::string line;
    
    std::ifstream in(eEnv::resolve("/etc/enigma2/settings").c_str()); //read out enigma2 setting file which has the lets say setting config.usage.e2_debug_level=1
    if (in.good()) {
		do {
			std::getline(in, line);
			size_t size = key.size();
			if (!line.compare(0, size, key) && line[size] == '=') {  // this line was the error in previous code
				value = line.substr(size + 1);
				break;
			}
		} while (in.good());
		in.close();
	}
   printf("config value for key = %s", value.c_str());
}

The print will be 1

 

cause You compare the first here 27 chars off lines with the key which is 27 long and You just compare:

 

"config.usage.e2_debug_level"(found line - the =1)  with  "config.usage.e2_debug_level" (the key)

 

read :

 

http://www.cplusplus...string/compare/


Edited by christophecvr, 7 February 2016 - 13:48.


Re: Enigma2 severe(blocker) bug caused by use off eDebug #39 christophecvr

  • Senior Member
  • 3,131 posts

+140
Excellent

Posted 7 February 2016 - 14:07

Think about something that is done here

 

https://github.com/O...tboxservice.cpp

 

with e.g. 

 

void eListboxServiceContent::setSize(const eSize &size)

void eListboxServiceContent::setGetPiconNameFunc(ePyObject func)

void eListboxServiceContent::setIgnoreService( const eServiceReference &service )

void eListboxServiceContent::setItemHeight(int height)

 

This changes values in "cpp".... with a call from python...

 

And the think in bsod.cpp I understand... Key is requested and it should be within the line... so I think christopher is right here.... he found another "bug" what is in there for more than 20 years...

And why is it bsod, the screen is green... ;)

 

my ubuntu build enviroment is somehow not stable so I cannot test this cpp change.

 Yes ,  I did not checked yet . But gues they will call the function into bsod.cpp called

void bsodFatal(const char *component)

So there indeed wee have the possibility that :

 

1) Python not down so yes that's the explanation off the lines in bsod.cpp

	std::string value = eConfigManager::getConfigValue(key.c_str());

	//we get at least the default value if python is still alive
	if (!value.empty())
		return value;

And the comment even confirms. this.

 

But ok next the skin used must be obtained. Should the python be crashed (does not mean that the box is crashed but actually only e2 is crashed)

std::string value = eConfigManager::getConfigValue(key.c_str());  will be NULL

 

so value.empty = empty.

 

Automatically (gues that will be part of the auto crash recovery  )

 

We continue  one line further value  is set to defaultValue

 

Then we poll also the e2 settings file for a skin setting.  But if this setting is not a default one ,

 

The goal should be to restart the recovered e2 with the skin mentioned into configs and not with the pli's general default skin. (That I gues)

 

Well unfortunately that will not happen but e2 crash auto restart will be with the default skin off pli and not with the user selected one cause the use off cplus compare option is wrong.

 

This all has nothing to to with what's is changed into enigma2.cpp concerning the debug.



Re: Enigma2 severe(blocker) bug caused by use off eDebug #40 mirakels

  • Forum Moderator
    PLi® Core member
  • 7,598 posts

+62
Good

Posted 7 February 2016 - 15:06

ok no I see what you changed. Next time just show a diff output of the versions and if you think that is not enoug, show the original version AND the diff.

Showing the before and after code makes it very hard to compare even if you mention line numbers (but fail to show the line numbers in the examples)

 

pushed your fix for it


Geen wonder... Had slechts een dm7000, maar wel ook een rotor. eigenlijk al een tijdje ook een dm600 en dm7025. Maar nu kijkend met een et9000 en vuduo


1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users