Avoid shutdown-time crash in wpa_supplicant.

Avoid shutdown-time crash in wpa_supplicant.

Change-Id: I1fafc5ed5a4bde2b1ac89ca7fa6bf9c3a132489e

BUG=chromium-os:8593
TEST=see if chromeos crash (from go/crash) with signature 9e97e (get_table_entry) goes away

Committed: http://chrome-svn/viewvc/chromeos?view=rev&revision=8e30eed

[Luigi Semenzato, 2011-04-07 22:26:51]

Looking at go/crash and go/uma, we're still getting about 1 crash/day, out of
about 8000 boots/day.  In theory I should try to reproduce this and verify that
it no longer happens with this CL, but I am afraid this might take a long time. 
Furthermore, it is easy to tell that the change is unlikely to do harm (we're
about to segv anyway).

[Will Drewry, 2011-04-07 22:38:24]

LGTM

Though I'm curious now since opencryptoki is being linked into Chrome too.  We
may need to track this down.  (However, it may be something like wpa_supplicant
dlclose() plus shutdown race conditions that we may never see.)  Anyway, this
will be good to keep in mind longer term.

I guess we'll see if this triggers crashes in a different place next :/

[Greg Spencer (Chromium), 2011-04-07 22:42:44]

On 2011/04/07 22:38:24, Will Drewry wrote:
> Though I'm curious now since opencryptoki is being linked into Chrome too.

opencryptoki is only loaded (dynamically, by NSS) if you specify
--load-opencryptoki on the command line, and I just checked that in this
morning, so I doubt if that has anything to do with it (yet!).

[Will Drewry, 2011-04-07 22:55:05]

On Thu, Apr 7, 2011 at 5:42 PM,  <gspencer@chromium.org> wrote:
> On 2011/04/07 22:38:24, Will Drewry wrote:
>>
>> Though I'm curious now since opencryptoki is being linked into Chrome too.
>
> opencryptoki is only loaded (dynamically, by NSS) if you specify
> --load-opencryptoki on the command line, and I just checked that in this
> morning, so I doubt if that has anything to do with it (yet!).


Hehe yeah - right now wpa_supplicant uses it via the openssl engine I
think so it could be an issue there.  The fini appears to be getting
called twice :/  Maybe when we move wpa_supp over to use NSS this will
go away anyhow. (I hope.)

[Luigi Semenzato, 2011-04-15 00:00:34]

I don't know why this happens unreliably.  Wpa_supplicant is single-threaded. 
Both libopencryptoki and libtspi have destructors.  The destructors are called
either at dlclose(), or after main() exits.  The opencryptoki destructor calls a
libtspi function which uses a data structure that is dismantled by the libtspi
destructor.  Maybe this call doesn't always occur, or maybe the process gets
killed before it gets a chance to segv.

On 2011/04/07 22:55:05, Will Drewry wrote:
> On Thu, Apr 7, 2011 at 5:42 PM,  <mailto:gspencer@chromium.org> wrote:
> > On 2011/04/07 22:38:24, Will Drewry wrote:
> >>
> >> Though I'm curious now since opencryptoki is being linked into Chrome too.
> >
> > opencryptoki is only loaded (dynamically, by NSS) if you specify
> > --load-opencryptoki on the command line, and I just checked that in this
> > morning, so I doubt if that has anything to do with it (yet!).
> 
> 
> Hehe yeah - right now wpa_supplicant uses it via the openssl engine I
> think so it could be an issue there.  The fini appears to be getting
> called twice :/  Maybe when we move wpa_supp over to use NSS this will
> go away anyhow. (I hope.)