97 replies to this topic

[christophecvr]

Thank's to Theparasol which reminded us that the eDebug does lock the e2 during logging and so caused sand keeper till box freezings for a while,

I tried out a new function which I made and called it eDebugNoLock. I tested it with the too extensif logging by servicemp3.cpp line 2089. Works perfect and to show I took just the streams who had that wild logging.

 

Included eDebugNoLock function add patch and very extensive log and it did runned all whitout sand keeper.

 

 

Attached Files

•  e2-eDebugNoLock-Function.patch   2.89KB   34 downloads
•  e2-log-witheDebugNoLock.txt   178.08KB   10 downloads

[christophecvr]

Oeps that was the wrong log here the right one

 

 

Attached Files

•  e2-log-witheDebugNoLock.txt   329.58KB   20 downloads

[christophecvr]

I see not much reaction on this topic .

 

Guess  the tittle is not that good It should have been.

 

"Enigma2 major bug caused by the use off eDebug"

Importance : major to critical.

 

The use off eDebug in enigma2 does cause regularly sand keeper short up to even full freeze off stb.

This is most probably one off the primary causes off the regularly run time errors during streaming, recording ,decoding and ....

Currently even the regular user does use always DEBUG mode  even if he does not log it on a console or file. That should not be.

 

What to do on this ?

 

1) I already started with for example eDebugNoLock, but guess it may cause other problems this.

2) Reduce the use off eDebug and Never use eDebug by logging off buffer issues the log I posted above did showed the problems.

 

Why logging is used ?

We need to see if the functions are working right. Need to have a way to identify a cause from a crash (unfortunately eDebug self is one off the causes).

 

When a error occurs and the we issue a eDebug that's fine since there was already error.

But like with the logging by the buffer there was no error in the function but we made one by logging the msg.

 

[arn354]

tried it and it solves the spinning issue - thx cvr

[littlesat]

What about arranging all eDebugs are nolock???

[christophecvr]

What about arranging all eDebugs are nolock???

I'm not shure but overthinking the process i'm afraid it could cause other issues such like data collisions.

 

But what well is each time buffering is seen disable eDebug  except for testing purpose You could enable a logging off it. Never in regular working mode. That's actually a trace mode and any trace used will always spoil the working off streaming and ....

the goal off that is trying to find an error . Say eighter the cause off A error.

All repetitive loops may not issue a eDebug, ok if a developer implements something new he will add a msg to check the working and especially with a loop it's important to check that it does not get stuck in loop.

But after the base working checked at least the eDebug should be commented.

Edited by christophecvr, 13 January 2016 - 11:20.

[christophecvr]

I think that a brainstorm about debugging in enigma2 is a good thing now.

 

But what well could be done by all developers is each time you work on something check the use off eDebug or any debug output. If not relevant in normal working situation in first place comment just the eDebug line (think about the ; if it was used into a if or if else )

[christophecvr]

Yes further research showed that not using the lock as a bad idea. Cause I need to lock the console and or file to which a log during the print phase.

 

It must be done on other ways.

[MastaG]

Chris, even if it's a bad idea, to not lock the buffer.

Did it break anything for you?

[WanWizard]

It seems logical not to do any debugging at all if you're not running in debug mode.

 

So what's needed is an option (if not present already) to start enigma2 from the commandline in debug mode without the need for a debug-enabled binary, and a code change to make sure eDebug calls are a NOP when debug mode is not enabled.

 

This is how most implementations work.

[christophecvr]

@WanWizard ,

 

At this time we do not have such a procedure implemented into enigma2 at all concerning the use off limiting the debug.

It is well a nice idea to implement that, with several debug levels and the possibility to let it debug only module based. Which could made it possible to even introduce a trace function.

At this time there is nothing as such present (or i did not found it ). This means it has to be made from scratch.

[christophecvr]

I just add her a patch for enigma2 servicemp3.cpp.

 

It will for now comment a couple off eDebug lines not relevant for standard working conditions and actually the one by the buffer was even a blocker (causes a real criticalto blocker bug)

 

I also comented a couple by the Handling off toc entries. (I even written self a comment that the eDebug was there for the first fase but should be removed after wards   ).

 

Then also by subtitles , The cause off why it could take sometimes a little seconds before the srt subtitle showed, exceptionally never showed up or sometimes showed up out off sync after a media resume operation is caused by the eDebug off it.

 

The reson why i did not removed the lines but just commented is, i'm thinking about future development , if with some persons we are joining the forces , perhaps we  may develop a nice debug utility which can be activated by for example a enigma2 extra start parameter such as is done by gstreamer for example.

 

It would be well be nice that this patch is committed since it's a real cause off some critical events using the servicemp3.cpp player.

 

 

Attached Files

•  e2-servicemp3-some-eDebug-commenting.patch   5.38KB   21 downloads

[littlesat]

You need the debugs for the crashlog.... Without debug mode is also something we should not prefer...
What should be solved is find a way we keep debugging and do not get the "hold-ups"...

And or consider a structured way to exclude or include the servicemp3 debugs with an option....

Edited by littlesat, 13 January 2016 - 13:41.

[christophecvr]

Chris, even if it's a bad idea, to not lock the buffer.

Did it break anything for you?

I did not test it by producing a specific situation where an error of it could occur, But

 

The problem which the NoLock may cause :

 

A writing at the same time from several modules to the log and that will cause freaky issues and must be scheduled to avoid data collision. This means if for example You would now set everywhere the eDebug whitout lock well I'm so what shure You will be pretty fast into real space issues and even much more freezes till even full stb crashes then now.

[MastaG]

So the best situation would be if everyone would just be careful what to log.

[christophecvr]

@littlesat,

 

Just cause that by a crash we need info for it is the reason that I opened this topic however the title is a bit wrong (can You correct that ?)

 

In general on this point we may absolutely not rush , since rushing on this may cause exactly the opposed of the goal. I must even admit that a was to fast with the eDebugNoLock function. I forgot to asses the overall project first and rushed.

 

That's why and also launch a call to all current developers contributors and core members to check where on other modules at this time eDebug is used and could cause a risk off high repetitive logging without sense  and so is just the cause off unstable conditions.

 

For the servicemp3.cpp I just set a patch with a very few ones . And only commented them in a first stage, this should be committed actually asap since they are al causing issues.

[christophecvr]

So the best situation would be if everyone would just be careful what to log.

Yes at this time well, And I self made this error regularly , since I thought the eDebug was harmless but it is absolutely not.

[christophecvr]

@littlesat do You like a pull request to apply  patch included in msg:

 

http://forums.openpl...ndpost&p=524543

 

or can You apply this very minimal but really urgent commented eDebugs. ? The commented lines will not have consequences for crash reports even the contrary at this time.

But all off them do cause issues. Due to the required lock used when printing eDebug.

[Taapat]

It seems logical not to do any debugging at all if you're not running in debug mode.

 

I for myself introduced in enigma printk level check: https://github.com/T.../eerror.cpp#L83
If I want to receiver work a little faster, and I do not need a log, I cut down prink level and I do not have in log unnecessary spam.

 

This definitely needs to be improved, but maybe you can use something similar.

[MastaG]

 

It seems logical not to do any debugging at all if you're not running in debug mode.

 

I for myself introduced in enigma printk level check: https://github.com/T.../eerror.cpp#L83
If I want to receiver work a little faster, and I do not need a log, I cut down prink level and I do not have in log unnecessary spam.

 

This definitely needs to be improved, but maybe you can use something similar.

 

 

+1 for that as well.

Reduce messages that don't add any value to debugging like in Chris' patch.

And also add some menu-option to completely disable it would be nice.

Edited by MastaG, 13 January 2016 - 16:08.