I have a program that can encrypt and decrypt a text with Boneh-Franklin encryption. This works great on a PC, but for some reason causes a constant reboot on ESP32 with the following error message:
setup2
setup2.2
setup2.3
Guru Meditation Error: Core 1 panic'ed (Unhandled debug exception)
Debug exception reason: Stack canary watchpoint triggered (loopTask)
Core 1 register dump:
PC : 0x40083774 PS : 0x00060b36 A0 : 0x3ffb0120 A1 : 0x3ffb0060
A2 : 0x68efa751 A3 : 0x3ffb0938 A4 : 0x3ffb0720 A5 : 0xfb879c5c
A6 : 0x61b36b71 A7 : 0x0006970f A8 : 0x01709af4 A9 : 0x01709af4
A10 : 0xfaa5dfed A11 : 0x01a3ff3b A12 : 0x76651dec A13 : 0x00000001
A14 : 0x00000000 A15 : 0x04adbe74 SAR : 0x0000001e EXCCAUSE: 0x00000001
EXCVADDR: 0x00000000 LBEG : 0x400f1cc5 LEND : 0x400f1cc9 LCOUNT : 0x00000000
ELF file SHA256: 0000000000000000
I use an Arduino ESP32 environment, CONFIG_ARDUINO_LOOP_STACK_SIZE is set to 8192 in main.cpp, 8k stack should be enough to run it. It works perfectly on PC, it’s a mystery to me why not on ESP32. Can anyone help? I absolutely ran out of ideas.
For the Boneh-Franklin implementation I used this library: https://github.com/miracl/core
My own code is ~200 lines, I have uploaded it to Google Drive: https://drive.google.com/file/d/1EY0mGC2UiVNhE68b5Q0VB9JIY2Owbpxg/view?usp=sharing
Looking at the code, it isn't unreasonable that the stack will require more than 8192 bytes as a lot of big objects are allocated on the stack, both in your code and in the library, e.g.:
loop()
csprng RNG – 128 bytes
ECP2 pPublic – 264 bytes
ECP2 cipherPointU – 264 bytes
ECP privateKey – 132 bytes
encrypt(...)
ECP pointQId – 132 bytes
char[] dst – 256 bytes
BIG l – 40 bytes
FP12 theta – 532 bytes
PAIR_fexp()
FP2 X – 88 bytes
BIG x – 40 bytes
FP a, b – 2 * 44 = 88 bytes
FP12 t0, y0, y1, y2, y3 – 5 * 532 = 2660 bytes
Increase your stack size. It will likely help.
I got to this page by googling my own troubles so thought I would add my solution here
I experienced this error recently and by using a series of Serial.println's was able to trace to an infinite loop created in the code
I'm currently trying to debug a Segmentation Fault: 11 on Mac in an executable produced by the DMD compiler, using LLDB.
The thing is I'm quite lost since I'm not too familiar with debugging tools.
All I do is start lldb with my binary and then execute the command run with the appropriate arguments. When the application crashes, I'm doing a thread backtrace and this is the output I'm getting:
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, address=0x7ffeef3fffd0)
frame #0: 0x00000001003f59e0 arturo`_D2gc4impl12conservativeQw14ConservativeGC__T9runLockedS_DQCeQCeQCcQCnQBs12mallocNoSyncMFNbmkKmxC8TypeInfoZPvS_DQEgQEgQEeQEp10mallocTimelS_DQFiQFiQFgQFr10numMallocslTmTkTmTxQCzZQFcMFNbKmKkKmKxQDsZQDl + 8
arturo`_D2gc4impl12conservativeQw14ConservativeGC__T9runLockedS_DQCeQCeQCcQCnQBs12mallocNoSyncMFNbmkKmxC8TypeInfoZPvS_DQEgQEgQEeQEp10mallocTimelS_DQFiQFiQFgQFr10numMallocslTmTkTmTxQCzZQFcMFNbKmKkKmKxQDsZQDl:
-> 0x1003f59e0 <+8>: movq %rbx, -0x50(%rbp)
0x1003f59e4 <+12>: movq %r12, -0x48(%rbp)
0x1003f59e8 <+16>: movq %r13, -0x40(%rbp)
0x1003f59ec <+20>: movq %r14, -0x38(%rbp)
Target 0: (arturo) stopped.
(lldb) thread traceback
invalid command 'thread traceback'.
(lldb) thread backtrace
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, address=0x7ffeef3fffd0)
* frame #0: 0x00000001003f59e0 arturo`_D2gc4impl12conservativeQw14ConservativeGC__T9runLockedS_DQCeQCeQCcQCnQBs12mallocNoSyncMFNbmkKmxC8TypeInfoZPvS_DQEgQEgQEeQEp10mallocTimelS_DQFiQFiQFgQFr10numMallocslTmTkTmTxQCzZQFcMFNbKmKkKmKxQDsZQDl + 8
frame #1: 0x00000001003ed77e arturo`_D2gc4impl12conservativeQw14ConservativeGC6qallocMFNbmkxC8TypeInfoZS4core6memory8BlkInfo_ + 122
frame #2: 0x00000001003f87a7 arturo`gc_qalloc + 59
frame #3: 0x00000001003e389f arturo`_D4core6memory2GC6qallocFNaNbmkxC8TypeInfoZSQBqQBo8BlkInfo_ + 43
frame #4: 0x00000001000037f3 arturo`_D3std5array__T8AppenderTAyaZQo13ensureAddableMFmZ9__lambda3MFNaNbNeZS4core6memory8BlkInfo_ + 43
frame #5: 0x000000010000372d arturo`_D3std5array__T8AppenderTAyaZQo13ensureAddableMFNaNbNfmZv + 269
frame #6: 0x00000001001d6a18 arturo`_D3std5array__T8AppenderTAyaZQo__T3putTAxaZQjMFQiZ10bigDataFunMFNaNbNfmZAa + 24
frame #7: 0x00000001001d69b1 arturo`_D3std5array__T8AppenderTAyaZQo__T3putTAxaZQjMFNaNbNfQoZv + 33
frame #8: 0x00000001000057b1 arturo`_D3std6format__T10FormatSpecTaZQp__T17writeUpToNextSpecTSQCd5array__T8AppenderTAyaZQoZQByMFNaNlNfKQBqZb + 121
frame #9: 0x0000000100023ab7 arturo`_D3std6format__T14formattedWriteTSQBg5array__T8AppenderTAyaZQoTaTQjZQCaFNaNfKQBsMxAaQBcZk + 103
frame #10: 0x0000000100023990 arturo`_D3std6format__TQkTaTAyaZQtFNaNfxAaQoZQr + 88
frame #11: 0x00000001001a1b6f arturo`_D5panic14getErrorStringFAyaQdAQgQdZQl + 1199
frame #12: 0x00000001001a2073 arturo`_D5panic31WARN_AssignmentInsideExpression6__ctorMFAyaZCQCbQBy + 227
frame #13: 0x00000001001a8847 arturo`_D6parser9statement9Statement7executeMFPC5value5ValuebZQp + 87
Any idea where to look? Seems like it has something to do with the Garbage Collector, but still not sure. Could it be an out-of-memory error?
Any pointers would be more than welcome!
this is a hard to reproduce bug, but I finally managed to reproduce it. However, I do not have a clear understanding of what might have caused it. I am currently trying to push myself through this bug and figure out the source of error.
Wondering if someone can give me some directions or hints.
My program is deadlocked in the stop function in Directshow Filter graph.
here is the call stack:
ntdll.dll!_ZwDeviceIoControlFile#40() + 0x15 bytes
ntdll.dll!_ZwDeviceIoControlFile#40() + 0x15 bytes
KernelBase.dll!_CreateEventExW#16() + 0x6e bytes
ksproxy.ax!SetState() + 0x3e bytes
ksproxy.ax!Inactive() + 0x3d bytes
ksproxy.ax!CKsOutputPin::Inactive() + 0x1d bytes
ksproxy.ax!CKsProxy::Stop() + 0x59 bytes
quartz.dll!CFilterGraph::Stop() + 0x123f3 bytes
quartz.dll!CFGControl::CImplMediaControl::Stop() + 0x12dba bytes <--- Called into direct show
*cam.dll!UVCCamera::Shutdown() Line 140 + 0x1b bytes C++
cam.dll!anonymous namespace'::closeCamera(unsigned int hCamera) Line 297 C++
cam.dll!anonymous namespace'::CoreThreadFunc(void * data) Line 916 + 0xb bytes C++
kernel32.dll!#BaseThreadInitThunk#12() + 0x12 bytes
ntdll.dll!__RtlUserThreadStart#8() + 0x27 bytes
ntdll.dll!_RtlUserThreadStart#8() + 0x1b bytes*
I may have solved this problem by using the method described at the end of the link below:
http://social.msdn.microsoft.com/Forums/en-US/windowsdirectshowdevelopment/thread/53563921-6398-491c-999c-3bfaa2f218ca/
Now I am getting a different error!
I have an application using DX11.
The debug build works well. But the release build crash on exit().
The stack:
000007fef697d630()
user32.dll!DispatchHookA() + 0x72 bytes
user32.dll!CallHookWithSEH() + 0x27 bytes
user32.dll!__fnHkINLPMSG() + 0x59 bytes
ntdll.dll!KiUserCallbackDispatcherContinue()
user32.dll!NtUserPeekMessage() + 0xa bytes
user32.dll!PeekMessageW() + 0x89 bytes
msctf.dll!RemovePrivateMessage() + 0x52 bytes
msctf.dll!SYSTHREAD::DestroyMarshalWindow() - 0x1b7a bytes
msctf.dll!TF_UninitThreadSystem() + 0xc4 bytes
msctf.dll!CicFlsCallback() + 0x40 bytes
ntdll.dll!RtlProcessFlsData() + 0x84 bytes
ntdll.dll!LdrShutdownProcess() + 0xa9 bytes
ntdll.dll!RtlExitUserProcess() + 0x90 bytes
msvcr100.dll!doexit(int code=0, int quick=0, int retcaller=0) Line 621 + 0x11 bytes
If I call LoadLibrary("d3d11.dll") before calling exit(), there is no crash.
I am looking at the code for the font file here:
http://www.openobject.org/opensourceurbanism/Bike_POV_Beta_4
The code starts like this:
const byte font[][5] = {
{0x00,0x00,0x00,0x00,0x00}, // 0x20 32
{0x00,0x00,0x6f,0x00,0x00}, // ! 0x21 33
{0x00,0x07,0x00,0x07,0x00}, // " 0x22 34
{0x14,0x7f,0x14,0x7f,0x14}, // # 0x23 35
{0x00,0x07,0x04,0x1e,0x00}, // $ 0x24 36
{0x23,0x13,0x08,0x64,0x62}, // % 0x25 37
{0x36,0x49,0x56,0x20,0x50}, // & 0x26 38
{0x00,0x00,0x07,0x00,0x00}, // ' 0x27 39
{0x00,0x1c,0x22,0x41,0x00}, // ( 0x28 40
{0x00,0x41,0x22,0x1c,0x00}, // ) 0x29 41
{0x14,0x08,0x3e,0x08,0x14}, // * 0x2a 42
{0x08,0x08,0x3e,0x08,0x08}, // + 0x2b 43
and so on...
I am very confused as to how this code works - can someone explain it to me please?
Thanks,
Majd
Each array of 5 bytes = 40 bits which map to the 7x5 = 35 pixels in the character grid (there are 5 unused bits presumably).
When you want to display a character you copy the corresponding 5 byte bitmap for that character to the appropriate memory location. E.g. to display the character X you would copy the data from font['X'].