4 ms·

While reading this article, it reminded me of an odd bug I encountered working with the Nitrogen Web Framework. I was finding that, similar to Patrick, it was

by chops 15y ago

While reading this article, it reminded me of an odd bug I encountered working with the Nitrogen Web Framework. I was finding that, similar to Patrick, it was losing sessions (though much more consistently), but only in Chrome and only with Yaws as the webserver. Switching to the Mochiweb server or Firefox caused the problem to go away. Firebug and Chrome's dev tools both reliably stated that the cookie header was indeed being set. I just didn't know why Firefox was accepting the cookies and holding the sessions, but Chrome was dropping the sessions. Oddly, it was only happening on my virtualbox dev environment, and not on any production machines. After much time, I noticed that the expiration date for the cookie was in the past. I hadn't noticed it before because it looked right (it correctly passed my mental regex for "looks like a good date"). It turned out the problem was being caused by my machine going to sleep, pausing everything (including the clock timer in the VirtualBox instance, which I leave on for weeks or months), causing the clock on the virtual server to get behind by several days. Then, when setting the cookie expiry date in max-age format, rather than absolute time, Mochiweb would send the Max-age expiration, which then gets handled by the browser relative to the receiving time. But Yaws would first take server time, add the seconds, and send that as the absolute expiration, effectively sending an past date to the browser as the expiration. Firefox, apparently, saw the cookie expiration date, and just said something like "Hey, we'll hold this until the user closes the tab or something", while chrome saw the expired cookie, and immediately expired it, appropriately. That's one of the weirdest non-bug bugs I've encountered. Note: when I say "Yaws" and "Mochiweb", I mean "Nitrogen's SimpleBridge connector for Yaws and Mochiweb".

chops 15y ago
Also (unrelated), My favorite quote from the article: "Race conditions are why sane programmers don’t program with threads or, if they do, they use shared-nothing architecture and pass all communication between the threads through a message queue written by someone who knows what they are doing (if you have to ask, it isn’t you — seriously, multithreaded programming is hard)." Sounds like an advertisement for Erlang :)
- adgar 15y ago
  Or Go. Though unlike Erlang processes, Go doesn't make mutating shared memory in multiple threads impossible. Go just makes it really easy to never do it.
  - jberryman 15y ago
    Or haskell with STM.
    - dkulchenko 15y ago
      Or ØMQ.
      - ansible 15y ago
        We're just starting a new project this week. It's not that complicated in the big scheme of things, but there are several bits of hardware that need to be coordinated which maintain their own state, plus a GUI, logging, and database updates. We'd initially talked about what modules and what main threads would be needed, but I started getting paranoid. So we're going to be using the Python multiprocessing library, and ZeroMQ plus JSON for the communication between the parts.
- runT1ME 15y ago
  You can absolutely have race conditions in Erlang, along with deadlocks too.
  - masklinn 15y ago
    Absolutely, but it tends to be significantly rarer, and easier to debug (in part due to tools, in other part due to OTP patterns) than multithreading race conditions. But yeah you can have race conditions in everything, you can also have race condition in non-threaded evented code (e.g. heavily async javascript client-side code)
gmac 15y ago
Similarly, one of the most banging-my-head-on-the-table bugs I've ever encountered caused all SSL connections from my iOS app to fail with an unhelpful 'something is wrong' message. Turned out my development iPhone's clock had just set itself back a few years, but I was so focused on the code that it took me a long time to figure that out.
- r00fus 15y ago
  You can't be faulted for that; aside from a few date-aware apps like calendar, where is the year displayed?

by chops 15y ago

chops 15y ago

Also (unrelated), My favorite quote from the article: "Race conditions are why sane programmers don’t program with threads or, if they do, they use shared-nothing architecture and pass all communication between the threads through a message queue written by someone who knows what they are doing (if you have to ask, it isn’t you — seriously, multithreaded programming is hard)." Sounds like an advertisement for Erlang :)

adgar 15y ago
Or Go. Though unlike Erlang processes, Go doesn't make mutating shared memory in multiple threads impossible. Go just makes it really easy to never do it.
- jberryman 15y ago
  Or haskell with STM.
  - dkulchenko 15y ago
    Or ØMQ.
    - ansible 15y ago
      We're just starting a new project this week. It's not that complicated in the big scheme of things, but there are several bits of hardware that need to be coordinated which maintain their own state, plus a GUI, logging, and database updates. We'd initially talked about what modules and what main threads would be needed, but I started getting paranoid. So we're going to be using the Python multiprocessing library, and ZeroMQ plus JSON for the communication between the parts.
runT1ME 15y ago
You can absolutely have race conditions in Erlang, along with deadlocks too.
- masklinn 15y ago
  Absolutely, but it tends to be significantly rarer, and easier to debug (in part due to tools, in other part due to OTP patterns) than multithreading race conditions. But yeah you can have race conditions in everything, you can also have race condition in non-threaded evented code (e.g. heavily async javascript client-side code)

gmac 15y ago

Similarly, one of the most banging-my-head-on-the-table bugs I've ever encountered caused all SSL connections from my iOS app to fail with an unhelpful 'something is wrong' message. Turned out my development iPhone's clock had just set itself back a few years, but I was so focused on the code that it took me a long time to figure that out.

r00fus 15y ago
You can't be faulted for that; aside from a few date-aware apps like calendar, where is the year displayed?