You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now this is very rr focused, but it would be good, IMO, to start thinking about what we can offer for non-rr capable systems. I'm thinking things like auto-uploading a manifest, perhaps a gdb backtrace or similar? Making it such that julia --bug-report gives us at least something (and that that something is as consistent as possible across platforms), then building BugReporting.jl to give us the capture and analysis tools to make squashing bugs fun and profitable.
Ideas of information we might want to know:
rr trace (only on x86_64-linux-gnu)
Manifest.toml (saved out in the bug report such that it's very easy for another dev to instantiate and see what's going on)
Basic system vital statistics; how many cores, how much RAM available, how much disk space available, etc... Help us quickly figure out if something is going to need specialized hardware/conditions to debug (like an OOM doing something nasty).
Would be cool if we could offer to auto-upload source code; In an rr context I know this will be automatically part of the trace and we can post-process it out, but it would also be nice if we could, for instance, hook into include() and copy all files that are included (filtering out things from base, stdlib and packages) into the tarball that gets uploaded. This could make it very easy to provide even moderate-size reproducers.
The text was updated successfully, but these errors were encountered:
Right now this is very
rr
focused, but it would be good, IMO, to start thinking about what we can offer for non-rr
capable systems. I'm thinking things like auto-uploading amanifest
, perhaps agdb
backtrace or similar? Making it such thatjulia --bug-report
gives us at least something (and that that something is as consistent as possible across platforms), then buildingBugReporting.jl
to give us the capture and analysis tools to make squashing bugs fun and profitable.Ideas of information we might want to know:
rr
trace (only on x86_64-linux-gnu)Manifest.toml
(saved out in the bug report such that it's very easy for another dev toinstantiate
and see what's going on)rr
context I know this will be automatically part of the trace and we can post-process it out, but it would also be nice if we could, for instance, hook intoinclude()
and copy all files that are included (filtering out things frombase
,stdlib
and packages) into the tarball that gets uploaded. This could make it very easy to provide even moderate-size reproducers.The text was updated successfully, but these errors were encountered: