Add the tor version and a newline to raw_assert()
We're missing a newline and the tor version in the logs for #31570 (moved).
Activity
changed milestone to %Tor: 0.3.5.x-final
added 035-backport 040-backport 041-backport BugSmashFund actualpoints::0.3 android component::core tor/tor consider-backport-after-042-stable dgoulet-merge diagnostics macos milestone::Tor: 0.3.5.x-final owner::teor points::0.1 priority::medium resolution::fixed reviewer::nickm severity::normal status::closed type::defect labels
See my pull request:
The remaining merges are clean, you can see the test branches bug31571_* at: https://github.com/teor2345/tor/branches
Gaba, I think this can be sponsor 31 can, because it helps us debug all our refactoring.
Trac:
Actualpoints: N/A to 0.1
Keywords: mmap, regression? deleted, macos, 041-backport, 040-backport, diagnostics, 035-backport added
Status: new to needs_review
Sponsor: N/A to Sponsor31-can
Points: N/A to 0.1
Cc: N/A to gabaReplying to teor:
See my pull request:
I changed the code to use strlcpy() and strlcat() rather than strncpy() and snprintf(), and pushed an updated branch.
The remaining merges are clean, you can see the test branches bug31571_* at: https://github.com/teor2345/tor/branches
I also added a refactor that simplifies the code, and a comment fix:
I put them on master, because they don't need to be backported.
I opened #31594 (moved) for the "close fds before abort" follow-up.
Trac:
Status: needs_revision to needs_reviewReplying to teor:
See my pull request:
The remaining merges are clean, you can see the test branches bug31571_* at: https://github.com/teor2345/tor/branches
It turns out that we can't use strlcpy() in lib/torerr, because strlcpy() is defined in lib/string on some platforms, and lib/string depends on lib/torerr.
I added a commit that checks the return values of snprintf() and strncpy() instead.
Trac:
Status: needs_revision to needs_review
The return-value checking looks okay to me.
I don't see any additional refactoring or comment changes on the master branch, however. Did they get eaten by a force-push? If you still want to do them, please put this back in needs_review when you're done. Otherwise this branch can go into merge_ready.
Trac:
Status: needs_review to needs_revisionReplying to nickm:
The return-value checking looks okay to me.
I don't see any additional refactoring or comment changes on the master branch, however. Did they get eaten by a force-push? If you still want to do them, please put this back in needs_review when you're done. Otherwise this branch can go into merge_ready.
I split the comment changes into #31612 (moved), they were unrelated to this PR. The refactoring wasn't possible due to layering issues with strlcpy(). So I just checked the return values in the 0.3.5 branch instead.
Trac:
Status: needs_revision to merge_readyThis is a complex series of changes, across multiple platforms. But it is well isolated. It does fix a real bug that we have encountered before, and it significantly improves error diagnostics, So we do want to backport, but not until after 0.4.2-stable.
Trac:
Cc: gaba to N/A
Actualpoints: 0.1 to 0.3
Keywords: N/A deleted, BugSmashFund, consider-backport-after-042-stable added
Sponsor: Sponsor31-can to N/A
Unparenting so I can close parent that was just merged.
Trac:
Parent: #31570 (moved) to N/APR 1277 merges fine to maint-0.4.1 using my git:
We want to backport this change to maint-0.3.5, so we can see a tor version every time tor crashes. Even on old tor versions :-)
Merged to 0.3.5 and later with #31810 (moved).
Trac:
Resolution: N/A to fixed
Status: merge_ready to closed
Milestone: Tor: 0.4.1.x-final to Tor: 0.3.5.x-finalmentioned in issue #31594 (moved)
mentioned in issue #31810 (moved)
mentioned in issue #32835 (moved)
moved to tpo/core/tor#31571 (closed)