First up, here's a dump of the jobs that you have registered.  I've put the names followed by the goal and state in brackets.  Then looked at the "cause" and "blocked" parameters, NULL means there wasn't one.

Please shout if any of this system state looks unusual to you:

rc jobs, all stopped:
  rcS (stop/waiting)  NULL  NULL
  rcS-sulogin (stop/waiting)  NULL  NULL
  rc0 (stop/waiting)  NULL  NULL
  rc1 (stop/waiting)  NULL  NULL
  rc2 (stop/waiting)  NULL  NULL
  rc3 (stop/waiting)  NULL  NULL
  rc4 (stop/waiting)  NULL  NULL
  rc5 (stop/waiting)  NULL  NULL
  rc6 (stop/waiting)  NULL  NULL

This is what I'd expect, the system has booted so there's no runlevel change going on right now.


tty jobs, both running:
  tty1 (start/running)  NULL  NULL
  tty2 (start/running)  NULL  NULL

Again, what we'd expect.


Now, a bunch of system services, some running, some not:
  autofs (start/running)  NULL  NULL
  acpid (start/running)  NULL  NULL
  haldaemon (start/running)  NULL  NULL
  messagebus (start/running)  NULL  NULL
  netplugd (start/running)  NULL  NULL
  prefdm (start/running)  NULL  NULL
  rsyslog (start/running)  NULL  NULL

  logd (stop/waiting)  NULL  NULL
  microcode_ctl (stop/waiting)  NULL  NULL
  netfs (stop/waiting)  NULL  NULL
  network (stop/waiting)  NULL  NULL
  serial (stop/waiting)  NULL  NULL
  sshd (stop/waiting)  NULL  NULL
  sulogin (stop/waiting)  NULL  NULL


Now your custom bits:

some jobs are stopped:
  ezono-cyclades-calibration  (stop/waiting)  NULL  NULL
  ezono-cyclades-pre-start  (stop/waiting)  NULL  NULL

  ezono-cyclades-t_ane (stop/waiting)  NULL  NULL
  ezono-cyclades-t_ccs (stop/waiting)  NULL  NULL
  ezono-cyclades-t_emg (stop/waiting)  NULL  NULL
  ezono-cyclades-t_mco (stop/waiting)  NULL  NULL
  ezono-cyclades-t_mse (stop/waiting)  NULL  NULL
  ezono-cyclades-t_par (stop/waiting)  NULL  NULL
  ezono-cyclades-t_pro (stop/waiting)  NULL  NULL
  ezono-cyclades-t_ssm (stop/waiting)  NULL  NULL
  ezono-cyclades-t_upg (stop/waiting)  NULL  NULL
  ezono-cyclades-t_xss (stop/waiting)  NULL  NULL

These might be "due to be started", but not yet reached, that's ok - if Upstart hasn't reached them they're not relevant yet.


some are running:
  ezono-cyclades-ac-adapter (start/running)  NULL  NULL
  ezono-cyclades-list-tasks (start/running)  NULL  NULL
  ezono-cyclades-stop-software-control (start/running)  NULL  NULL
  ezono-cyclades-suspend-control (start/running)  NULL  NULL
  ezono-cyclades-xss-control (start/running)  NULL  NULL
  ezono-malta-fpga-control (start/running)  NULL  NULL

  ezono-cyclades-t_bbd (start/running)  NULL  NULL
  ezono-cyclades-t_cal (start/running)  NULL  NULL
  ezono-cyclades-t_dso (start/running)  NULL  NULL
  ezono-cyclades-t_fcl (start/running)  NULL  NULL
  ezono-cyclades-t_fem (start/running)  NULL  NULL
  ezono-cyclades-t_emg-control (start/running)  NULL  NULL
  ezono-cyclades-t_mco-control (start/running)  NULL  NULL
  ezono-cyclades-t_prd (start/running)  NULL  NULL
  ezono-cyclades-t_scp (start/running)  NULL  NULL
  ezono-cyclades-t_smr (start/running)  NULL  NULL
  ezono-cyclades-t_ssc (start/running)  NULL  NULL
  ezono-cyclades-t_upg-control (start/running)  NULL  NULL

These are just running normally, there's no "cause" for them (ie. they're defined as services - I didn't actually verify this, for all of them, but I suspect it's true - if you could make sure that'd be great)


Now we also have some running tasks that retain their start cause:
  ezono-cyclades-gui-start-condition-control (start/running)  0x9a0d9a0 started enzono-cyclades-t_bgr (handling 1)  NULL

  ezono-cyclades-t_bgr (start/running)  0x9a0ec98 restart-bgr (handling 1)  NULL

  ezono-cyclades-t_wdg (start/running)  0x9a0dc68 stopped ezono-cyclades-pre-start ok (handling 1)  NULL


Some jobs are starting up based on the same event:
  ezono-cyclades-t_hal (start/pre-start)  0x9a0e720 start-ezono-cyclades-gui (handling 6)  NULL
  ezono-cyclades-t_rvs (start/pre-start)  0x9a0e720 start-ezono-cyclades-gui (handling 6)  NULL
  ezono-cyclades-t_scv (start/pre-start)  0x9a0e720 start-ezono-cyclades-gui (handling 6)  NULL
  ezono-cyclades-t_spl (start/pre-start)  0x9a0e720 start-ezono-cyclades-gui (handling 6)  NULL
  ezono-cyclades-t_svs (start/pre-start)  0x9a0e720 start-ezono-cyclades-gui (handling 6)  NULL
  ezono-cyclades-t_upn (start/pre-start)  0x9a0e720 start-ezono-cyclades-gui (handling 6)  NULL

Which all looks ok.


And then we have three which are in valid states of starting, but have an invalid pointer for their cause:
  ezono-cyclades-t_fbs (start/pre-start)  0x9a0eb48 INVALID  NULL
  ezono-cyclades-t_ime (start/pre-start)  0x9a0eb48 INVALID  NULL
  ezono-cyclades-t_ltl (start/spawned)  0x9a0eb48 INVALID  NULL
  ezono-cyclades-usb-storage (start/running)  0x9a0eb48 INVALID  NULL

It was the third of these (start/spawned) that crashed the daemon, but any of the other two would have crashed it the minute they reached start/spawned.

I find it interesting that the fourth one is in start/running


In the events list we have:
  0x9a0dc68 stopped ezono-cylades-pre-start ok (handling 1)
  0x9a0ec98 restart-bgr (handling 1)
  0x9a0d9a0 started ezono-cylades-t_bgr (handling 1)
  0x9a0e720 start-ezono-cyclades-gui (handling 6)
  0x9aa7e20 started ezono-cyclades-t_prd (pending 0)
  0x9a0eb20 started ezono-cyclades-t_scp (pending 0)


These numbers match up to the others, so other than the mysterious 0x9a0eb48 event, the data has integrity