Skip to content
Snippets Groups Projects
  1. Aug 27, 2006
    • deuce's avatar
      Only run the programs main() function in a separate thread if the program · 5d14c047
      deuce authored
      was linked with ciolib.  This seems to work perfectly on *nix and is untested
      on Win32.
      
      This *should* fix all the SDL-related stupidities that were occuring
      previously (second system() call killing the program, etc).
      
      Testers welcome!
      5d14c047
    • deuce's avatar
      Check the current real and effective IDs (user and group) before calling · 3fd75078
      deuce authored
      setre?id() since new systems apparently hang on that call when the IDs
      are already what you want.  Further, use a single mutex to protect both
      do_setuid() and do_seteuid().
      
      The symptoms:
      When you connect to the BBS, the user prompt would repeat quickly three
      times then drop carrier on you.  Nothing you entered ever showed up.
      --OR--
      You seem to connect to the BBS, but you never see any output.
      
      This was only easily reproduced when starting the system as a non-root
      user.
      
      This has been confirmed on FC3, FC4, and Debian etch.
      
      
      The cause:
      output_thread or input_thread called thread_up() which called do_seteuid()
      which hung in setregid().  Since do_seteuid() is holding a mutex at this
      point, when the other *put_thread calls thread_up(), it waits forever for
      the mutex.  If output_thread starts first, this results in getchr()
      returning ^C every time it's called since input_thread_running is false.
      
      
      Question for DigitalMan:
      Should output_thread/input_thread post a semaphore when they're up to prevent
      SMP systems from getting far enough into answer() to call IO stuff before the
      corresponding thread is running?  A timed semaphore wait in main.cpp then
      could be used (you wouldn't want to block forever in case this happens again).
      3fd75078
    • deuce's avatar
      No need to do this twice. · c7a0de8b
      deuce authored
      c7a0de8b
  2. Aug 26, 2006
  3. Aug 25, 2006
    • deuce's avatar
      Add a unbaja.brute file when brute forcing. This is a cache of found · 4d9b39f6
      deuce authored
      variable names in the format:
      XXXXX,#,STR
      Where XXXX is the hex value of the CRC
      # is zero if this is a bad match and non-zero if it's a good match.
      STR is the variable string.
      
      If you run unbaja with brute-forcing, and it makes a BAD match, adjust the
      second value in the line and run it again to brute-force ignoring the bad
      match.
      
      At some point, I may have it pick up from the last variable.
      4d9b39f6
  4. Aug 24, 2006
  5. Aug 23, 2006
  6. Aug 22, 2006
Loading