33 replies to this topic

[Huevos]

https://github.com/O...728b6438cdb1193

 

This commit is not working right. It falls over printing a python dict.

 

Here is my .py debug code:

print "NIT raw section", section

Here is what "section" contains:

NIT raw section {'content': [{'orbital_position': 642, 'symbol_rate': 220000, 'roll_off': 0, 'polarization': 1, 'original_network_id': 2, 'fec_inner': 4, 'frequency': 1150850, 'modulation_type': 1, 'modulation_system': 0, 'descriptor_tag': 67, 'transport_stream_id': 2092, 'west_east_flag': 1}, {'orbital_position': 642, 'symbol_rate': 220000, 'roll_off': 0, 'polarization': 0, ...

With this commit this is what is printed to debug:

NIT raw section {'content': [{'orbital_position': 642, 'symbol_rate': 220000, 'roll_off': 0, 'polarization': 1, 'original_network_id': 2, 'fec_inner': 4, 'frequency': 1150850, 'modulation_type': 1, 'modulation_sy˜, "¶Ú
¸±¨¬£¶
¸±¨¬£¶
¸±X•¶

After that enigma2 freezes and puts up an endless spinner.

Edited by Huevos, 24 February 2016 - 01:53.

[littlesat]

During some investigation work a few days ago I also saw strange things with debugging showing a python dict... I have the feeing that "extreme" long python debugs strings might be an issue... The output is limited to 1024 characters...

Edited by littlesat, 24 February 2016 - 08:19.

[Huevos]

Thanks Littlesat. If there is a limit it needs removing otherwise debug is now useless. And even worse, it is making enigma freeze.

 

Also, looking at the old code there was already the same limit on buffer size, but this didn't prevent the whole dict getting printed to the debug log.

 

In my opinion the debug system should be able to handle anything that gets thrown at it. Otherwise how are we supposed to debug anything?

Edited by Huevos, 24 February 2016 - 09:26.

[Taapat]

@Huevos or you use the latest enigma?
Now the python debug output looks like this: https://github.com/O...541b3bc4f6f298f
For me, it fix enigma freeze, but I have not tested very long strings.

 

http://forums.openpl...bugging-system/

Edited by Taapat, 24 February 2016 - 09:59.

[Huevos]

I'm using the latest e2 code including that commit.

The commit I linked to breaks debug. This is 100 percent repeatable. E2 prints out some garbage then freezes. After that it needs a reset from the rocker switch.

[littlesat]

See it as work in progress.... Thanks for the observation and then try investigate futher and improve it...

[Huevos]

See it as work in progress.... Thanks for the observation and then try investigate futher and improve it...

Not sure what you mean. Previously it would print anything. Now it won't even print a python dict.

 

How are you supposed to debug if debug itself is broken.

[littlesat]

I just checked...it prints small python dicts as far I can see....

[littlesat]

Please do not draw conclusions that quickly as It has nothing to do with a python dict...

 

I tested it...

 

Indeed as soon when we have a row of more than 1024 (1K) characters it goes wrong.... Hopefully Milo could take a look at it... 

[betacentauri]

https://github.com/O...eerror.cpp#L150

pos += vsnprintf(buf + pos, sizeof(buf) - pos, fmt, ap);

According to spec of vsnprintf:
"If the resulting string would be longer than n-1 characters, the remaining characters are discarded and not stored, but counted for the value returned by the function."

 

If I understand right, then pos can be greater than 1024 (sizeof(buf) - pos is max 1024) after execution. So you maybe access data not assigned to buf.

[Huevos]

P

Indeed as soon when we have a row of more than 1024 (1K) characters it goes wrong.... Hopefully Milo could take a look at it... 

Yes I tested too and found the same.

 

I don't know if this 1024 limit was intentional (obviously freezing enigma was not). Previously the debug size was unlimited. Hopefully it can be made unlimited again.

 

Thanks Betacentauri.

[mirakels]

Added quick fix to avoid the weird prints, but output will be truncated. A better solution needs to be crafted....

[littlesat]

Thanks mirakels...

[Huevos]

Certainly does. What use is a debug system if it only prints a small token of the full debug output?

[mirakels]

Certainly does. What use is a debug system if it only prints a small token of the full debug output?

Well, the commit log says it is a quick fix for now and a better solution should be created. The quick fix is to avoid a big mess...

 

On the other hand, what good can it be to just spit out a big pile of data in a single line that probably noone will have the device for to show it as a single line.

Such debug messages should be better formatted.

A sort of general rule should that a single debug line should not normally exceed 100 characters or so.

[Huevos]

It is not a big pile of data. It is a python dict. If the debug system starts cutting it about it will be useless.

 

With the old debug system you could copy and paste from the output straight into a piece of code without having to repair the the data being printed out.

 

What is the problem with having one line of debug printed out on one line?

[Huevos]

And, with the current "fix" no newline is being added when output is over 1024.

'modulation_type': 1, 'modulation_sy<   808.935> [gRC] main thread is non-idle! display spinner!

Edited by Huevos, 25 February 2016 - 15:30.

[Huevos]

The way I see it the debug system should print exactly what the code tells it. If you start adding formatting in the debug system how is it ever going to be useful for debugging code?

[littlesat]

Be patient!

And note when you display big lines you could also arrange in your debug code to split it... It can even make your debugging much more readable.... In case of a dict display the values you need...

Edited by littlesat, 25 February 2016 - 16:02.

[Huevos]

Sorry if I seem impatient.

 

I just want to be able to print the dict. i.e.

print dict

I want to see it exactly as python sees it. Not some formatting add later by the CPP code.

 

If that doesn't fit in the console display it doesn't matter as it can be read in the Putty log. The important thing is that it is a virgin untouched copy of the original dict.