I'm calling AudioSessionInitialize like so
OSStatus result = AudioSessionInitialize(NULL,NULL,interruptionListener,NULL);
and getting the result 0xbfffde94 (i.e. -1073750040) which doesn't match anything in the documentation, which are all readable 4CC's like '!ini' and so forth.
The good news is that it seems like the call worked. Nevertheless, can anyone shed light on this error code?
EDIT: The above error code is returned in the simulator. On the device the error code is 2fffe810.
Since these results are bogus and not defined or described by Apple, I am left with only but one assumption; you have a weird mix of Frameworks installed - possibly old versions mixed with newer ones. So all I could recommend is to reinstall the entire iPhone SDK.
I figured it out. I'm an idiot. There was an error in the macro I had wrapping the call & reporting the error, which called the AudioSessionInitialize twice. That doesn't quite explain the error code I saw, but it sure isn't worth wondering about.
UPDATE: Actually this is pretty slapstick so I'm going to explain.
The offending macro was originally:
#define CHECK(S) { OSStatus err = (S); if (S) printf("Error %x at \"%s\"\n", err, #S);}
so bug #1 is the if (S) which should be if if (err). Hence I'm repeating every call to the audio system, which explains various other weird things, so I'm very happy I tried to figure out what had seemed like a harmless anomaly. In this case the second call complained that the audio session was already initialized.
But why the weird error code? I wanted to see the 4CC's so I changed the macro to this, carrying the error along:
#define CHECK(S) { OSStatus err[2] = {S,0}; if (S) printf("Error %x '%4s' at \"%s\"\n", err, &err, #S); }
(The second OSStatus of 0 terminates the string defined by the 4CC first OSStatus, so I can print it with format %s.) But I forgot to change err to err[0], so it was indeed printing the address of the err array. This I'm pretty sure is correct now:
#define CHECK(S) { OSStatus err[2] = {S,0}; if (*err) printf("Error %x '%4s' at \"%s\"\n", *err, err, #S); }
Look at the OSStatus variable in the debugger's list of variables (lower left). Right click on it and select View Value As->Bytes (Hex with ASCII). Read the 4-letter code backwards.* This should match one of the documented result codes.
A value of 1768843636 is 74 69 6e 69 when viewed this way. Next to that the debug window shows 'tini'. Turn that around and you get 'init', which the documentation says is kAudioSessionAlreadyInitialized.
*No, I don't know why.
Related
I have tested two cases:
I use STEPCAFControl_Reader then STEPControl_Reader to read my step file but both methods crash when I call STEPCAFControl_Reader::Transfer, repsectively STEPControl_Reader:: TransferRoots.
By using STEPControl_Reader, I displayed a log on my console, then there is a message like this:
1 F:(BOUNDED_SURFACE,B_SPLINE_SURFACE,B_SPLINE_SURFACE_WITH_KNOTS,GEOMETRIC_REPRESENTATION_ITEM,RATIONAL_B_SPLINE_SURFACE,REPRESENTATION_ITEM,SURFACE): Count of Parameters is not 1 for representation_item
EDIT:
There is a null reference inside TransferRoots() method.
const Handle(Transfer_TransientProcess) &proc = thesession->TransferReader()->TransientProcess();
if (proc->GetProgress().IsNull())
{
//This condition does not exist from the source code
std::cout << "GetProgress is null" << std::endl;
return 0;
}
Message_ProgressSentry PS ( proc->GetProgress(), "Root", 0, nb, 1 );
My app and FreeCAD crash but if I use CAD Assitant which OCC official viewer, it loads.
It looks like comments already provide an answer to the question - or more precisely answers:
STEPCAFControl_Reader::ReadFile() returns reading status, which should be checked before calling STEPCAFControl_Reader::Transfer().
Normally, it is a good practice to put OCCT algorithm into try/catch block and check for OCCT exceptions (Standard_Failure).
Add OCC_CATCH_SIGNALS at the beginning of try statements (required only on Linux) and OSD::SetSignal(false) within working thread creation to redirect abnormal cases (access violation, NULL dereference and others) to C++ exceptions (OSD_Signal which is subclass of Standard_Failure). This may conflict other signal handlers in mixed environment - so check also documentation of other frameworks used by application.
If you catch failures like NULL dereference on calling OCCT algorithm with valid arguments - this is a bug in OCCT which is desirable to be fixed in one or another way, even if input STEP file contains syntax/logical errors triggering such kind of issues. Report the issue on OCCT Bugtracker with sufficient information for reproducing bug, including sample files - it is not helpful to developers just saying that OCCT crashes somewhere. Consider also contributing into this open source project by debugging OCCT code and suggesting patches.
Check STEP file reading log for possible errors in the file itself. Consider reporting an issue to system producing a broken file, even if main file content can be loaded by STEP readers.
It is a common practice to use OSD::SetSignal() within OCCT-based applications (like CAD Assistant) to improve their robustness on non-fatal errors in application/OCCT code. It is more user friendly reporting an internal error message instead of silently crashing.
But it should be noted, that OSD::SetSignal() doesn't guarantee application not being crashed nor that application can work properly after catching such failure - due to asynchronous nature of some signals, the memory can be already corrupted at the moment, when C++ exception has been raised leading to all kinds of undesired behavior. For that reason, it is better not ignoring such kind of exceptions, even if it looks like application works fine with them.
OSD::SetSignal(false); // should be called ones at application startup
STEPCAFControl_Reader aReader;
try
{
OCC_CATCH_SIGNALS // necessary for redirecting signals on Linux
if (aReader.ReadFile (theFilePath) != IFSelect_RetDone) { return false; }
if (!aReader.Transfer (myXdeDoc)) { return false; }
}
catch (Standard_Failure const& theFailure)
{
std::cerr << "STEP import failed: " << theFailure.GetMessageString() << "\n";
return false;
}
return true;
I'm writing a simple program to decode any input audio file into pcm16/mono/wav file, using libav. Or, I supposed it was simple.
After struggling a lot, reading lots of sample code (like avconv/avplay), I've managed to code something that should work.
However, it's not working. The demuxing/decoding parts seems to work fine, but the encoding part failed with the following message:
mathematics.c:61: av_rescale_rnd: Assertion `c > 0' failed.
Here is the code extract:
printf("Fill Frame\n");
avcodec_fill_audio_frame(oframe, _oCodecCtx->channels, _oCodecCtx->sample_fmt, frame->data[0], frame->linesize[0], 0);
printf("Frame filled\n");
ret = avcodec_encode_audio2(_oCodecCtx, &opkt, oframe, &got_packet);
if (ret < 0) {
printf("Error encoding audio frame\n");
return 1;
}
"Fill Frame" And "Frame filled" are displayed before the error appears. So, I think its thrown by avcodec_encode_audio2. However, this function doesn't call av_rescale_rnd in its source code.
So here is the question: is there a way to know who called this function, without modifying/recompiling libav source code?
I, recently I use fopen_s:
errno_t err = fopen_s( &fp, filename, mode );
and I get errno_t as zero, which means no error occured, but I didn't get a valid fp, actually, it is unchanged.
What possible is this situation?
Apparently, it encounter a NULL file pointer, which is not as expected, for why it encounter such a problem, please refer to this: Bad Pointer error when using File* object
It's some kind of annoying:
Since I started using the MPMoviePlayerController the console is overfilled with information from MPAVController.
Eg:
[MPAVController] Autoplay: _streamLikelyToKeepUp: 1 -> 1
[MPAVController] Autoplay: Disabling autoplay
This is some kind of annoying because I always have to search for my own logged information.
Is there a way to turn off logging for specific objects or frameworks?
I don't think such filtering is possible out of the box. But it's possible to redirect stderr (which is used by NSLog) into a pipe, read from that pipe in a background thread and then print messages that pass through the filter onto stdout (which is captured by the debugger as well). This code does the job:
int main(int argc, char *argv[])
{
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_LOW, 0), ^(void) {
size_t const BUFFER_SIZE = 2048;
// Create a pipe
int pipe_in_out[2];
if (pipe(pipe_in_out) == -1)
return;
// Connect the 'in' end of the pipe to the stderr
if (dup2(pipe_in_out[1], STDERR_FILENO) == -1)
return;
char *buffer = malloc(BUFFER_SIZE);
if (buffer == 0)
return;
for (;;)
{
// Read from the 'out' end of the pipe
ssize_t bytes_read = read(pipe_in_out[0], buffer, BUFFER_SIZE);
if (bytes_read <= 0)
break;
// Filter and print to stdout
if (should_show(buffer)) // TODO: Apply filters here
fwrite(buffer, 1, bytes_read, stdout);
}
free(buffer);
close(pipe_in_out[1]);
});
// Rest of main
}
Please note that this code is quite simple and doesn't handle all corner cases. First of all it captures all stderr output and not just NSLog. Maybe this could be filtered out by checking against the content. NSLog output always starts with the date and time.
Second problem with this code is that it doesn't try to split/join strings it reads from the pipe. There's no guarantee that there will be one NSLog per read. They could be coming together or be too long and would be split. To handle this it would require additional processing of the data read from the pipe.
Anyway, for many practical purposes this should be enough.
You should look into NSLogger. While NSLog doesn't give you any selectivity about what you see from run to run, NSLogger can. NSLogger displays output from the device (or simulator) in its own window in OS X.
Basically it adds the concept of facility and level to output. Unix wizards might find fault with this comparison but I see it as very similar to syslog. The NSLogger viewer lets you display output messages for one or more facilities (which you define) which also meet the minimum level required.
Macros define what you see in the output window. Here's an excerpt:
#ifdef DEBUG
#define LOG_GENERAL(level, ...) LogMessageF(__FILE__,__LINE__,__FUNCTION__,#"general",level,__VA_ARGS__)
#else
#define LOG_GENERAL(...) do{}while(0)
#endif
When DEBUG is off, no messages appear. When on, if you have a LOG_GENERAL() statement in code and your viewer is configured to display facility "general" and your level is sufficient to be displayed, you get a message.
It's incredibly flexible and I like it a lot. It takes about five minutes to add to your project. Please take a look at the github page linked above for full details and download.
(This will not solve the problem of MPAVController filling the console with messages, but it does put the messages you want in a new window, making it much easier to control, filter and interpret what you are interested in.)
Another option, if you can use it, is to run either a simulator or a device running iOS < 6.0.
The MPAVController log messages do not appear for me when using a 5.0 device or the 5.1 Simulator. But they definitely appear in the 6.0 Simulator.
Of course one should generally use the current OS, but if one is working on a video heavy section of a project, running an earlier simulator or device while working on that particular set of tasks is a way to alleviate this logging headache.
This also provides some backward compatibility testing as a bonus.
I'm a beginner in Perl and I get this message when I execute my code:
Use of uninitialized value $triggerCheck in numeric gt (>) at
./advanced-daemon.pl line 101.
This is the only error/warning I get when executing my code. The code, itself, works without any problems but I'm wondering what's the problem in that variable?
To reproduce the problem you can use this code:
while(1==1)
{
my $triggerCheck = "10";
if($triggerCheck < 10)
{
print "This var is < 10";
}
$triggerCheck = 9;
sleep 1;
}
Edit: I solved my problem. Sorry for bothering you all :)
There is absolutely nothing wrong with that code that you initially posted. Nor the code that you replaced it with (other than the annoying infinite loop).
It gets no errors or warnings and, when I change the initialisation to "9", it outputs the string.
In fact, given that your error message is complaining about > and there's no such symbol anywhere in your code, you have a serious mismatch between reality and your presentation of it.
Seriously, put together the minimal complete code sample that generates the error and post that. Helping people over the net is hard enough without being hobbled by fiction :-)