Attachment nvda-old.log added by jjimenez0 on 2015-03-06 07:06
Description:
nvda log

Attachment nvda_crash.dmp added by jjimenez0 on 2015-03-06 07:06
Description:
dump of memory

Comment 2 by jteh on 2015-03-16 05:37
liblouis definitely shouldn't cause access violations. So, you're definitely triggering a bug in liblouis.

That said, the actual crash seems to be when exiting another thread and liblouis doesn't spawn threads. Are you spawning any threads in your driver? It's still possible that liblouis is indirectly causing this by corrupting memory.

If you're familiar with such things, try running NVDA inside WinDBG and seeing if you can reproduce the problem. You've got more of a chance of catching errors that way.

For reference, here's the stack dump:

(dbc.e24): Access violation - code c0000005 (first/second chance not available)
eax=00000000 ebx=078d3f28 ecx=00510000 edx=005f6930 esi=078d3ee8 edi=077eef1c
eip=774c0c32 esp=077eebdc ebp=077eebec iopl=0         nv up ei pl zr na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000246
ntdll!ZwGetContextThread+0x12:
774c0c32 83c404          add     esp,4
0:015> .ecxr
eax=005ed5d0 ebx=005f6930 ecx=00510000 edx=005f6930 esi=49b5b96c edi=005f6928
eip=774ce39e esp=077efecc ebp=077eff00 iopl=0         nv up ei pl nz na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010206
ntdll!RtlpLowFragHeapFree+0x31:
774ce39e 8b4604          mov     eax,dword ptr [ds:002b:49b5b970=????????
0:015> kp
  *** Stack trace for last set context - .thread/.cxr resets it
ChildEBP RetAddr  
077eff00 774ce003 ntdll!RtlpLowFragHeapFree+0x31
077eff18 754d14dd ntdll!RtlFreeHeap+0x105
077eff2c 1e11e1db kernel32!HeapFree+0x14
077eff44 73b43433 python27!bootstrap(void * call = 0x005f6930)+0x1b [c:\build27\cpython\python\thread_nt.h @ 122](esi+4])
077eff7c 73b434c7 msvcr90!_endthreadex+0x44
077eff88 754d33ca msvcr90!_endthreadex+0xd8
077eff94 774d9ed2 kernel32!BaseThreadInitThunk+0xe
077effd4 774d9ea5 ntdll!__RtlUserThreadStart+0x70
077effec 00000000 ntdll!_RtlUserThreadStart+0x1b

Comment 3 by norrumar on 2015-05-04 08:52
Hi, trying EcoBraille driver NVDA has been restarted automatically with a similar bug.
Thanks.

Attachment nvda_crash.2.dmp added by norrumar on 2015-05-04 08:58
Description:
Crash dump

Attachment nvda-old.2.log added by norrumar on 2015-05-04 08:59
Description:
Log file.

Comment 4 by norrumar on 2015-05-04 09:13
I don't know if this can be fixed setting the timeout to the normal value (1). I have done it and NVDA seems to start with a minor delay and Ecobraille works fine for me.
When timeout is set to 3, I think NVDA seems to start too slowly.
Thanks.

Comment 5 by norrumar on 2015-05-04 10:57
Hi, decreasing timeout doesn't fix this. I don't know if this is similar to the bug reported with BRLTTY on #5039 ticket.

We believe this to be the same underlying cause as #4457. A fix is now available for testing in the latest "next" branch snapshots.