web died after successful print
-
(deleted, not relevant)
-
@JoergS5 said in web died after successful print:
@arhi but some overflow is the reset reason of your last reset. Maybe the cash overflow above, or another overflow. For overflow reasons, I only found the recursion as a cause, but maybe you're first for your overflow reason.
Well, the board did not reset! As I wrote, only the HTTP module or NET module died (did not restart, stayed dead), everything else continued to work ok as nothing happens, continued printing, parsing g-code...
-
@arhi The M122 reset reason is the reason of the reset 131 hours ago. The error 10 could be related to this access error.
-
@JoergS5 yup, that M122 happened before the ~130 hours of inactivity
-
This post is deleted! -
here it comes again, ~12 hours of inactivity, dead 5 minutes after the print finished ?!?!
-
@arhi what is the M122 please?
-
@JoergS5 I didn't do M122 I just rebooted it, turned on debugging on net, web and few others turned on logging on serial port and let it run so it catches log if it happens again as even dc42 did not find anything useful in the m122 last time so .. collecting debug data now
-
@arhi ok, hope you find something. Good luck!
-
@JoergS5 said in web died after successful print:
@arhi ok, hope you find something. Good luck!
I'm not turning the darn debug off till the darn thing dies again so we'll see .. -
not crashing while debugging turned on ...
interesting thing, no apps connecting to duet (rpi with duetlapse off, web browser closed all the tabs referencing it on all computers...) and I see this in the debug:
Received 57 bytes Received 793 bytes Received 132 bytes Received 47 bytes Received 85 bytes Received 174 bytes Received 49 bytes Received 174 bytes Received 237 bytes Received 174 bytes Received 174 bytes Received 50 bytes Received 85 bytes Received 56 bytes Received 158 bytes Received 47 bytes Received 85 bytes Received 47 bytes Received 85 bytes Received 47 bytes Received 85 bytes Received 47 bytes Received 85 bytes Received 47 bytes Received 85 bytes Received 47 bytes Received 85 bytes Received 174 bytes Received 174 bytes Received 174 bytes Received 174 bytes Received 116 bytes Received 97 bytes Received 97 bytes Received 325 bytes Received 317 bytes Received 1435 bytes Received 353 bytes Received 47 bytes Received 85 bytes Received 47 bytes Received 85 bytes Received 47 bytes Received 85 bytes Received 132 bytes Received 47 bytes Received 85 bytes Received 174 bytes Received 174 bytes Received 174 bytes Received 174 bytes Received 56 bytes Received 158 bytes Received 47 bytes Received 85 bytes Received 47 bytes Received 85 bytes Received 174 bytes Received 174 bytes Received 174 bytes Received 174 bytes Received 57 bytes Received 793 bytes Received 47 bytes Received 85 bytes Received 47 bytes Received 85 bytes Received 455 bytes Received 1435 bytes Received 237 bytes Received 50 bytes Received 65 bytes Received 174 bytes Received 174 bytes Received 174 bytes Received 174 bytes Received 56 bytes Received 158 bytes Received 47 bytes Received 85 bytes Received 132 bytes Received 47 bytes Received 85 bytes Received 47 bytes Received 85 bytes Received 47 bytes Received 85 bytes Received 47 bytes Received 85 bytes Received 39 bytes Received 77 bytes Received 97 bytes Received 97 bytes Received 174 bytes Received 174 bytes Received 174 bytes Received 174 bytes Received 52 bytes Received 353 bytes Received 47 bytes Received 85 bytes Received 47 bytes Received 85 bytes Received 82 bytes Received 41 bytes Received 41 bytes Received 56 bytes Received 158 bytes?! received what from who?
-
@arhi there is always a bit of network traffic like ICMP broadcasts. To analyze, you need wireshark or similar and your pc network card in promiscuous mode. But the switch might hinder traffic analysis.
-
@JoergS5 said in web died after successful print:
@arhi there is always a bit of network traffic like ICMP broadcasts. To analyze, you need wireshark or similar and your pc network card in promiscuous mode. But the switch might hinder traffic analysis.
yeah I have wireshark but the printer is on managed switch that does have bunch of fancy options but does not allow sniffing
and I don't have any hub's around any moreit's idle for ~20 hours now I'll try to print something later afternoon with debugging on, who knows maybe I reproduce the issue
-
managed switch and no mirror option?
if its on a pi tough you can run tcpdump over ssh and pipe it to wireshark
-
@bearer said in web died after successful print:
managed switch and no mirror option?
Yeah, I run few dlink "Smart Copper Gigabit Switch DGS‑1224T" and if they have the option to mirror I did not find it
(I had a need for this few times already). I had one 100mbps 4 port hub I used to use for analyzing traffic but it died last year and with this ^#$^%#$#@! hitting the planet I did not get new one yet..if its on a pi tough you can run tcpdump over ssh and pipe it to wireshark
yeah, no, its duet2 and I have not tried, yet, the duet2->sbc connection...
-
can't reproduce the darn thing, running debug for almost a week, giving it 24-70 hours break, everything works like expected ..
-
@arhi debug changes runtime behaviour, seems to be an error which is affected by debug unfortunately. Maybe there are other possibilities to analyze the error, debug turned off (like memory dumps). If you want to dig deep, SWD debugging would be possible. Duet 2 did not expose SWD, but there was a thread here how this could be done. Duet 3 has the pins exposed.
From your profile description I saw you know servers. In my job many years ago we had a server with memory leak, and we didn't find the solution. The "solution" was to reboot the server every night. This might be a "solution" for this problem also, if the cost-benefit to find the solution becomes too bad.
-
@JoergS5 said in web died after successful print:
@arhi debug changes runtime behaviour
writing software for 30+ years
well aware of that ugly fact SWD debugging would be possible
not an option
my electronics table is on the other side of the room from the printer and time required for doing that does not exist; we are talking about debugging an issue that I cannot reproduce on-demand, I'd spend time better doing code review than debugging it
.. unfortunately, time does not allow much more than storing a console log and reporting results -
I'm a super-duper newb, but learning about embedded programming right now. Is this why, in one talk on the subject, someone recommended never testing in debug? In fact, I think they said to never have a distinction of debug vs release.
-
@bot said in web died after successful print:
I'm a super-duper newb, but learning about embedded programming right now. Is this why, in one talk on the subject, someone recommended never testing in debug? In fact, I think they said to never have a distinction of debug vs release.
I wouldn't pay too much attention to what that person has to say
There's 2 distinction types between "debug" and "non-debug" (release) "versions" (it's actually a configuration / target) and they do not differ in embedded system vs any other system.
-
you include debug data in your code or not (debug data contain all the symbols in the binaries so you know what the real name of a function at some address is, what the name of a variable is etc etc, so when you are using a debugger it's much easier to trace what the hack is going on). These "debug informations" are just a blob of data added to the binary in most cases, for e.g. on unix you can use "strip" to remove that data from the binary, and most debugging tools allow you to have this data even in a separate file. If you look at RepRapFirmare release there are Symbols-* files with this information. With regular gdb for e.g. you would do
add-symbol-file filename addressor if you have the symbols in one place you configure gdb withset debug-file-directory <directory>and gdb loads them as it needs them (if it can recognise them by name). This type of "distinction" makes ZERO difference between debug and release, your code will execute the same way -
you modify the app behavior. This does not have to be compile time decision at all and you can do this for many other targets, not only debug. For e.g. you are working with a new sensor so you'll write a piece of code like
... d = fetcDataFromSensor(x,y,z); __PRINT(d); dealWithSensorData(d); ...where the __PRINT() would be something like
... #ifdef DEBUG //do some thing, send stuff trough serial, blink leds, send data to lcd ... #else // do nothing #endifBut you can also do this programatically, like for e.g. RRF send additional "debug" info to the usb port if you turn "additional data" (debug) for a certain module
This second type is VERY USEFUL, but, it does change your code path so some issues can be masked as the code path is not the same
-
