Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
Trac
Trac
  • Project overview
    • Project overview
    • Details
    • Activity
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Operations
    • Operations
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Create a new issue
  • Issue Boards

GitLab is used only for code review, issue tracking and project management. Canonical locations for source code are still https://gitweb.torproject.org/ https://git.torproject.org/ and git-rw.torproject.org.

  • Legacy
  • TracTrac
  • Issues
  • #18306

Closed (moved)
Open
Opened Feb 12, 2016 by teor@teor

Avoid using tor_assert before the logging system is fully initialised

In #18241 (moved), we discovered that an assertion failure that occurs before or during the initialisation of the logging system causes an infinite loop.

We need to check tor and the tools for these kinds of issues.

In particular, the logging system initialises the log mutex. tor_mutex_init() can still call tor_assert if it fails, so the possibility of this stack overflow still exists when we're initialising the log mutex itself.

Now these kinds of failures don't happen very often, and if they do, it's unlikely tor would ever launch. But it would be better to use fprintf(stderr, ...); in these circumstances so that users can see the actual log message.

To upload designs, you'll need to enable LFS and have admin enable hashed storage. More information
Assignee
Assign to
Tor: unspecified
Milestone
Tor: unspecified
Assign milestone
Time tracking
None
Due date
None
Reference: legacy/trac#18306