Tvheadend

You need to provide some more info

Attach yourself to the container via bash & kill tvh then run with..

--debug http --trace http --logfile /tmp/http.log

Generate the error then use nc to upload the log..

cat /tmp/http.log | nc termbin.com 9999

post the log here.

Torbjørn Brekke wrote:

... snip..

Thank you for giving the correct info in order to Help debug this issue. I don't use docker much so can only give hints :).

I think Jaroslav would need a trace/debug info. See Debugging & Traces for info. How you'd go about that in docker I have no clue.

Mark Clarkstone wrote:

Torbjørn Brekke wrote:

... snip..

Thank you for giving the correct info in order to Help debug this issue. I don't use docker much so can only give hints :).

I think Jaroslav would need a trace/debug info. See Debugging & Traces for info. How you'd go about that in docker I have no clue.

I'll read that page and enable what is needed. Might need to get info about which parts to add to debug if more than http is needed. But I guess Jaroslav can point in the right direction.

Torbjørn Brekke wrote:

Mark Clarkstone wrote:

Torbjørn Brekke wrote:

... snip..

Thank you for giving the correct info in order to Help debug this issue. I don't use docker much so can only give hints :).

I think Jaroslav would need a trace/debug info. See Debugging & Traces for info. How you'd go about that in docker I have no clue.

I'll read that page and enable what is needed. Might need to get info about which parts to add to debug if more than http is needed. But I guess Jaroslav can point in the right direction.

I think the CRASH lines would be more than enough :), but yes, Jaroslav will be the best to decide here.

http.log file uploaded to termbin

http://termbin.com/pptm

Shout if you need anything else...

Thanks all

dp

The docker image should contain addr2line tool (binutils) and the debugging binary (with unstripped debugging symbols) should be used to get reasonable CRASH lines. Also, try to put a sleep between 'rerun'.

It may not work. It seems that musl does not implement backtrace functions (execinfo.h). You need gdb to debug this. https://sourceware.org/gdb/onlinedocs/gdb/Remote-Debugging.html

Thanks Jaroslav

gdb debugging (remote or otherwise) is a bit beyond me I'm afraid.

@Torbjørn - If you can provide similar pointers as you did in post #2,I'm happy to do some work on this to return some useful debug info.

Thanks all

dp

David Pollard wrote:

Thanks Jaroslav

gdb debugging (remote or otherwise) is a bit beyond me I'm afraid.

@Torbjørn - If you can provide similar pointers as you did in post #2,I'm happy to do some work on this to return some useful debug info.

Thanks all

dp

It's just easier that I debug it here. I have to test that the container with gdb works anyway.

Jaroslav Kysela wrote:

It may not work. It seems that musl does not implement backtrace functions (execinfo.h). You need gdb to debug this. https://sourceware.org/gdb/onlinedocs/gdb/Remote-Debugging.html

I remember now that I tried to find execinfo.h for alpine before and didn't succeed. I'll try to get gdb backed into a container here.

Thanks, fixed. v4.3-889-g6d00befe8

Jaroslav Kysela wrote:

401 errors are fine for requests without authorization. 500 error code - it seems that it is probably returned from http_serve_file() function after "bad" lseek() call in src/webui/webui.c . Could you check what value is returned from lseek() for musl ?

I could check it, but I have no idea how to check it I'm afraid.

I added the error log to recent v4.3-907-gfb22b9565. Please, retry and repost logs.

If you run gdb in this way, could you add breakpoint to http_serve_file, like:

$ gdb --args ...
(gdb) l http_serve_file
(gdb) l
(gdb) break 1466
(gdb) run
(gdb) until 1488
...

etc.. We need to find a line where the program returns with the 500 error code (HTTP_CODE_INTERNAL).

Is there something more you want me to test?

Upgrade to master - I added more traces to '--trace http' subsystem.