It has always been random. No definite chronic specific circumstantial variables involved. I'm somewhat confident that maybe once all of the .css / webUI code tweaks are done, it may settle out. We'll see. <wink>
A while back I traced similar problems back to thread exceptions in HTTPd, and farther into uClibc. This is really a combination BusyBox / uClibc / ARM soft float issue and uClibc really needs to be compiled with options more lenient (safer and less performant) for this hardware. What you end up seeing is thread exceptions during concurrency and the aborted http requests are the threads that aborted.
Also, older versions of GCC emit questionable compiled output for ARMv7 and up, and this is also seen across OpenWRT / Entware / Optware. A change to a real libC would be of benefit for platforms that have ample space.
Almost all routers use glibc and are compiled with gcc10 or higher.
The debugging I did was not on DD, but showed that compilation adjustments were necessary for uClibc concurrency to perform properly under older GCC builds.
What I’m getting at is that there are probably concurrency bugs that still remain and less-aggressive compilation flags may benefit DD, even if using a complete libc, simply because of ARM soft float and unaddressed ARM ABI bugs in GCC.
It is certainly possible that there are thread exceptions due to compiler optimization.
I am not an expert in optimizations my knowledge stops at setting O2 or Os
I actually compile with O2 and see very little problems but maybe I should look more carefully.
I would habitually be cautious of -Os on platforms where GCC has to insert its own math code because the ABI doesn’t include support for float or double precision math. You literally tell the compiler to insert extra code to emulate an FPU, and in the next pass tell it to strip out as much as it can (for size) without knowing how much overlap (if any) exists between the two and practical limitations to how that stripping affects soft-FPU routines.
Of course compiler designers are supposed to take these corner cases into account, but my suggestion is to leave optimization at -O or enable -Werror to flush out subtle warnings as build-stopping errors. If size is still too large, then reconsider why uClibc exists for embedded projects in the first place.
Another, more extreme, suggestion for compilation auditing is to compile in both GCC and CLANG and verify warnings across both tools, as each will detect and lint code with different tables. For ARM this gets a little harder as the soft-FPU code is not the same across the tools.
Bad memories of early GCC and SUN Forte compiling on Sparc prior to US-II…however, I caught a lot of bugs in GCC running it up against a commercial compiler.