I have an OpenSL ES function call that causes no problems in one application, but causes a problem in another application, both run on the same device.
The line is:
result = slCreateEngine(&engineObject, 0, NULL, 0, NULL, NULL);
Where result is of the type SLresult, engineObject is of the type SLObjectItf
The error I seem to get is:
05-19 11:56:27.007: ERROR/libOpenSLES(1425): slCreateEngine while another engine 0x299fa0 is active
It seems this is not logged from my code, but maybe it is caused by it? So what could cause this line to produce an error in one app, but not in the other?
As it happens to be, it was partly Android's Activity life-cycle which caused the error, but mostly my own fault. It was caused by the onCreate() and onResume() methods Android provides for an Activity. I never thought of the fact that onResume() also get's called when an Activity is started. Because of this, I never realized that I had a 2nd call to the slCreateEngine function.....
According to the docs "OpenSL ES for Android supports a single engine per application". I had a quick check of the source for OpenSL an I can see this is enforced by a global storing the current active engine.
So if you want to call slCreateEngine, you must make sure all other engines have been destroyed first. This includes the possibility of any 3rd party code you are linking in too (incase you are linking in something else that is creating an OpenSL engine object before you do).
Related
I'm learning DirectX12 and writing some utility classes to encapsulate functionality. Right now I'm working on mechanism for pooling CommandLists.
The pool assumes all command lists are closed. I wanted to validate that during inserting to the pool, but I can't manage to check it. From MSDN:
Returns S_OK if successful; otherwise, returns one of the following
values:
E_FAIL if the command list has already been closed, or an invalid API was called during command list recording.
Which is precisely what I'm looking for, but when I call ID3D12GraphicsCommandList::Close() to validate, it throws exception in KernelBase.dll. It looks really bizarre to me. Is this specification incompliance?
//EDIT: I cannot catch the exception, even with catch(...). It tells me maybe something may be wrong with my setup, but everything else is working for me.
I am running my application in VS2012 and I am getting a runtime error;
When I look in the "Original Location" I see mscorlib.dll, but not mscorlib.pdb.
Why is this happening and how do I fix it?
Goto Tools, Options, Debugging, General, Enable Just My Code
This will prevent the debugger from trying to launch on a Internal .NET Framework Assembly.
Goto Tools, Options, Debugging, Symbols and set a cache location. Then hit load in the above and it will fetch the necesary symbols for you and store them in the cache location you provide.
Microsoft's compiler tools create symbols in separate files with a .pdb extension (program database). This allows them to create detached symbols for release binaries. With a symbol server, your IDE can fetch the symbol file matching the specific version of the DLL during debugging. You can configure this system for your own product binaries as well which can be very useful for post-mortem debugging any crashes on end-user machines.
See Microsoft's documentation for more details about using their public symbols.
I had this issue when I was using a static variable, whose value is assigned off a static method.
So, whenever I ran the application, this line of code threw exception. If you place a debug point on this (like I did), you will notice the exception being thrown.
The best Solution to solve this error is:
1: Open App.config file.
2: Paste this useLegacyV2RuntimeActivationPolicy="true" code in the startup tag.
3: Save it.
Now the error would disappear.
Moreover see Image. I have done this for you.
This happened to me for a different reason: I had referenced an old version of NLog (2.0) and needed to reference version 4.0, instead.
In a VB console app, in my case it was none of the above.
Just doing a string calculation in the Dim declarations before my subs.
The offending code:
Dim FylPrefix$ = Fyl.Substring(0, Fyl.LastIndexOf("."))
Moving this calculation into the sub it was needed in fixed it! GERONIMO!!
This can happen when you initialize a variable in your class declarations and that initialization throws an exception:
class Program
{
static OracleConnection ora = getOracleConnection();
}
static void main(string[] args)
{
ora.Open();
}
static OracleConnection getOracleConnection()
{
OracleConnection orax = new OracleConnection(description=(host=myHost)
(port=1521)(protocol=tcp))(connect_data=(sid=mySid)));user id=user;password=pw;
}
If an exception is thrown by getOracleConnection() you can get this error. Move your assignment (but not necessarily your declaration) inside of main (where it belongs anyway), and you will get the actual exception that is causing the error instead of the mscorlib error.
In my case the exception began to appear after I changed the "Assembly name" in the "Application" tab of the properties window. If that's the case with you try reverting to the original name and see if the exception disappears.
Perhaps the reason for this was that the new name did not match the AssemblyTitle in AssemblyInfo.cs.
if you have this type of project runtime error in visualstudio
Answer:Cntr+Alt+E open Exception window Uncheck All chechboxes
Must and shoud its working written by B sriram Mca Giet College
rajahmundry, east godavary ,2014 batch
I have looking at many threads about the exception "cannot pass a GCHandle across AppDomains" but I still don't get it....
I'm working with an RFID Reader which is driven by a DLL. I don't have source code for this DLL but only a sample to show how to use it.
The sample works great but I have to copy some code in another project to add the reader to the middleware Microsoft Biztalk.
The problem is that the process of Microsoft Biztalk works in another AppDomain. The reader handle events when a tag is read. But when I run it under Microsoft Biztalk I got this annoying exception.
I can't see any solution on how to make it work...
Here is some code that may be interesting :
// Let's connecting the result handlers.
// The reader calls a command-specific result handler if a command is done and the answer is ready to send.
// So let's tell the reader which functions should be called if a result is ready to send.
// result handler for reading EPCs synchronous
Reader.KSRWSetResultHandlerSyncGetEPCs(ResultHandlerSyncGetEPCs);
[...]
var readerErrorCode = Reader.KSRWSyncGetEPCs();
if (readerErrorCode == tKSRWReaderErrorCode.KSRW_REC_NoError)
{
// No error occurs while sending the command to the reader. Let's wait until the result handler was called.
if (ResultHandlerEvent.WaitOne(TimeSpan.FromSeconds(10)))
{
// The reader's work is done and the result handler was called. Let's check the result flag to make sure everything is ok.
if (_readerResultFlag == tKSRWResultFlag.KSRW_RF_NoError)
{
// The command was successfully processed by the reader.
// We'll display the result in the result handler.
}
else
{
// The command can't be proccessed by the reader. To know why check the result flag.
logger.error("Command \"KSRWSyncGetEPCs\" returns with error {0}", _readerResultFlag);
}
}
else
{
// We're getting no answer from the reader within 10 seconds.
logger.error("Command \"KSRWSyncGetEPCs\" timed out");
}
}
[...]
private static void ResultHandlerSyncGetEPCs(object sender, tKSRWResultFlag resultFlag, tKSRWExtendedResultFlag extendedResultFlag, tKSRWEPCListEntry[] epcList)
{
if (Reader == sender)
{
// Let's store the result flag in a global variable to get access from everywhere.
_readerResultFlag = resultFlag;
// Display all available epcs in the antenna field.
Console.ForegroundColor = ConsoleColor.White;
foreach (var resultListEntry in epcList)
{
handleTagEvent(resultListEntry);
}
// Let's set the event so that the calling process knows the command was processed by reader and the result is ready to get processed.
ResultHandlerEvent.Set();
}
}
You are having a problem with the gcroot<> helper class. It is used in the code that nobody can see, inside that DLL. It is frequently used by C++ code that was designed to interop with managed code, gcroot<> stores a reference to a managed object. The class uses the GCHandle type to add the reference. The GCHandle.ToIntPtr() method returns a pointer that the C++ code can store. The operation that fails is GCHandle.FromIntPtr(), used by the C++ code to recover the reference to the object.
There are two basic explanations for getting this exception:
It can be accurate. Which will happen when you initialized the code in the DLL from one AppDomain and use it in another. It isn't clear from the snippet where the Reader class object gets initialized so there are non-zero odds that this is the explanation. Be sure to keep it close to the code that uses the Reader class.
It can be caused by another bug, present in the C++ code inside the DLL. Unmanaged code often suffers from pointer bugs, the kind of bug that can accidentally overwrite memory. If that happens with the field that stores the gcroot<> object then nothing goes wrong for a while. Until the code tries to recover the object reference again. At that point the CLR notices that the corrupted pointer value no longer matches an actual object handle and generates this exception. This is certainly the hard kind of bug to solve since this happens in code you cannot fix and showing the programmer that worked on it a repro for the bug is very difficult, such memory corruption problems never repro well.
Chase bullet #1 first. There are decent odds that Biztalk runs your C# code in a separate AppDomain. And that the DLL gets loaded too soon, before or while the AppDomain is created. Something you can see with SysInternals' ProcMon. Create a repro of this by writing a little test program that creates an AppDomain and runs the test code. If that reproduces the crash then you'll have a very good way to demonstrate the issue to the RFID vendor and some hope that they'll use it and work on a fix.
Having a good working relationship with the RFID reader vendor to get to a resolution is going to be very important. That's never not a problem, always a good reason to go shopping elsewhere.
I notice Debug.Assert does not trigger in Metro apps, however, if the project is a traditional one like Console or WinForm, it does trigger. And yes, I am in Debug mode.
Is it a setting not properly set in Visual Studio (11 Beta)? Or Debug.Assert is intended to be disabled in metro apps?
I know many exceptions are swallowed during the execution of Metro apps, but Debug.Assert is so handy that I can't think of a reason why it should be disabled.
Seems like a bug. I would roll out my own assert method. Something like:
[Conditional("DEBUG")]
public static void Assert(bool condition)
{
if (!condition)
System.Diagnostics.Debugger.Break();
}
It does trigger, look in the Output window. It just doesn't automatically prompt you to ask if you want a debugger break and thus just keeps motoring.
The DefaultTraceListener.AssertUIEnabled property is false. That's an implementation problem, can't display a message box on top of Metro UI. Which does actually work but the monitor switches to the desktop, pretty undesirable when you would have liked to click No. Hard to solve and no doubt on the todo list. You can't easily get to the property to set it to true, it is inaccessible from the metadata. Filip's workaround sounds half-decent.
There is the same problem with F# in WinRT, in VS2013. The assert statement, which is an alias for System.Diagnostics.Debug.Assert, does not raise an exception, so unless you are watching the Output window then your assertions can fail without being noticed. Even if you are watching, it is hard to find the spot where the assertion was raised.
I followed Filip's suggestion and wrote a short utility, as follows:
namespace MyProj.Infrastructure
module Diagnostics =
let Assert condition = if not condition then
System.Diagnostics.Debugger.Break()
I chose Debugger.Break over raising an exception because it stops the debugger at the place the assertion fails. However, raising an exception is an acceptable alternative.
I didn't have any suitable global projects or modules already in my solution, so I had to create them just for this, which was quite annoying.
I'm triying to use Media Foundation to play mp3 file and I have a problem getting PresentationDesctiptor using CreatePresentationDescriptor method
What am I doing:
Start MF using MFStartup
Create session using MFCreateMediaSession
Create SourceResolver using MFCreateSourceResolver
Create MediaSource using CreateObjectFromURL from SourceResolver
Create topology using MFCreateTopology
Trying to create PresentationDescriptor using CreatePresentationDescriptor from MediaSource
When I call CreatePresentationDescriptor no error/exception occurs it just stands there and does nothing. When I pause Visual Strudio it indicates that program is still waiting for method to finish. What am I doing wrong ?
I did not metion that I use C# for this (did not think this was relevant)
The problem was that when importing com interfaces in C# you need to import all methods of interface not only those that are called. Some methods can call not imported methods and cause Access Violation that is not reported to Visual Strudio debugger and as a result it seems like method is never finished invokink.