ThrawnCA

Our fork worked around this by introducing a fallback into the `url_for` helper, letting it use `/dataset` if a custom dataset type fails, but it is not an elegant solution.

I'm inclined to switch off the SonarQube rule, or at least greatly turn down the severity. The standard `clone` implementation has some gotchas, but that doesn't make it useless.

I think we'd prefer not to add dependencies, since SpotBugs should be compatible with as many projects and systems as possible. Thanks for the suggestion, though.

> I bet this can only be reproduced with a specific server backend response Our backends are Jetty 9.4.57 instances, serving a simple directory: /hb /webapps/heartbeat false The server configuration...

More digging revealed the `pstack` utility. $ pstack core core 'core' of 11475: /apps/haproxy/bin/haproxy-3.1.7-solaris-sparc -f /tmp/poc.conf ffffffff7eccb470 __lwp_sigqueue (0x6?, 0xffffffff7fffdb30?, 0x5?, 0x5?, 0x0?, 0x0?) + 8 ffffffff7ebe51dc abort (0x137?, 0x1?,...

I tried the patch but encountered the same result :| $ pstack core core 'core' of 23986: /apps/haproxy/bin/haproxy-3.1.7-hotfix-solaris-sparc -f /tmp/poc.conf ffffffff7eccb470 __lwp_sigqueue (0x6?, 0xffffffff7fffdbc0?, 0x5?, 0x5?, 0x0?, 0x0?) + 8...

Update: I have tested (vanilla) 3.0.10 and it does not crash.

I have successfully tested 3.2.1 and can confirm the crash is fixed :) Do you need feedback on any of the dev versions to determine which one fixed it?

IMO writing to a stream qualifies as changing its state. Especially with classes like `ByteArrayOutputStream`.

This has a lot more in it than just ignoring 'write' methods...