Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>A KERN-EXEC 3 panic is caused by an unhandled exception (CPU fault) generated by trying to invalidly access a region of memory. This invalid memory access can be for both code (for example, bad PC by stack corruption) or data (for example, accessing freed memory). As such these are typically observed when dereferencing a NULL pointer (it is equivalent to a segfault).</p> <p>Certainly the call to RLibrary::Load should never raise a KERN-EXEC 3 due to programmatic error, it is likely to be an environmental issue. As such I have to speculate on what is happening.</p> <p>I believe the issue that is observed is due to stack overflow. Your MMP file does not specify the stack or heap size the initial thread should use. As such the default of 4Kb (if I remember correctly) will be used. Equally you are using TFileName - use of these on the stack is generally not recommended to avoid... stack overflow.</p> <p>You would be better off using the _LIT() macro instead - this will allow you to provide the RLibrary::Load function with a descriptor directly referencing the constant strings as located in the constant data section of the binary.</p> <p>As a side note, you should check the error value to determine the success of the function call.</p> <pre><code>_LIT(KMyDllName, "mydll.dll"); _LIT(KMyDllPath, "c:\\sys\\bin\\"); RLibrary dll; TInt res = dll.Load(KMyDllName, MyDllPath); // Hopefully no Kern-Exec 3! if(err == KErrNone) { TLibraryFunction f = dll.Lookup(1); if (f) f(); } // else handle error </code></pre>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload