Recent

Author Topic: Exception: SIGILL?  (Read 19577 times)

SirLucifer

  • New member
  • *
  • Posts: 18
Exception: SIGILL?
« on: January 28, 2010, 03:51:08 pm »
This is the second SIGxxx exception I've come across, and I really don't like these *NIX messages.
What does this mean?  That a signal is ill, or what? Of course it is... I'm on Windows, we don't have signals...
Well... Enough comedy.

Honestly, what does it mean?

Some code:

Code: [Select]
uses
  DShow { and a bunch of other stuff }

Procedure TAnalyzer.Check(Result: HResult);
begin
  If Failed(Result) Then
    Raise Exception.Create(SysErrorMessage(Result));
end;

Function TAnalyzer.AnalyzeDirectX: Boolean;
Var Err          : HResult;
    Filename     : WideString;
    GraphBuilder : IGraphBuilder;
    MediaControl : IMediaControl;
    MediaEvent   : IMediaEvent;
begin
  Check(CoCreateInstance(CLSID_FilterGraph, Nil, CLSCTX_INPROC, IID_IGraphBuilder, GraphBuilder));
  Try
    Check(GraphBuilder.QueryInterface(IID_IMediaControl, MediaControl));
    Check(GraphBuilder.QueryInterface(IID_IMediaEvent, MediaEvent));
    Filename := UTF8ToSys(Files[FileIndex]);
    Check(GraphBuilder.RenderFile(PWideChar(Filename), Nil));  // <--- Exception here!
  Finally
    MediaEvent := Nil;
    MediaControl := Nil;
    GraphBuilder := Nil;
  End;
end;

Regards all!

theo

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1890
Re: Exception: SIGILL?
« Reply #1 on: January 28, 2010, 04:10:58 pm »

SirLucifer

  • New member
  • *
  • Posts: 18
Re: Exception: SIGILL?
« Reply #2 on: January 28, 2010, 04:19:34 pm »
Thanks theo!

It seems I'm calling an illegal function, but how is that really possible when the first two functioncalls of that interface is ok and successful?

theo

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1890
Re: Exception: SIGILL?
« Reply #3 on: January 28, 2010, 04:35:42 pm »
I have no idea what you're doing.
From googling I've found this.
http://www.c-plusplus.de/forum/viewtopic-var-t-is-254847.html
Maybe you're missing somthing?

Anyway, this is also problematic:

Filename := UTF8ToSys(Files[FileIndex]);

I do not think it is the reason for the errror, but you should use
UTF8Decode instead of UTF8ToSys which returns an AnsiString.

SirLucifer

  • New member
  • *
  • Posts: 18
Re: Exception: SIGILL?
« Reply #4 on: January 28, 2010, 10:59:00 pm »
Quote
I have no idea what you're doing.

What I'm trying to do, is parse a video using DirectShow.
Following the example at http://msdn.microsoft.com/en-us/library/dd389098%28VS.85%29.aspx I can't really see what I'm missing.
What's missing in my original post, though, is the call to CoInitialize, which occurs right before the call to TAnalyzer.AnalyzeDirectX.

Anyone got a suggestion?

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 6674
Re: Exception: SIGILL?
« Reply #5 on: January 30, 2010, 04:13:42 pm »
Quote
I have no idea what you're doing.

What I'm trying to do, is parse a video using DirectShow.
Following the example at http://msdn.microsoft.com/en-us/library/dd389098%28VS.85%29.aspx I can't really see what I'm missing.
What's missing in my original post, though, is the call to CoInitialize, which occurs right before the call to TAnalyzer.AnalyzeDirectX.

Anyone got a suggestion?

I don't know if it is the problem, but try to add

  filename:=filename+' ';

 AFTER the

  Check(GraphBuilder.RenderFile(PWideChar(Filename), Nil));  // <--- Exception here!

line.

SirLucifer

  • New member
  • *
  • Posts: 18
Re: Exception: SIGILL?
« Reply #6 on: January 31, 2010, 12:21:06 pm »
Thanks for the replies.

marcov,
Quote
I don't know if it is the problem, but try to add

  filename:=filename+' ';

 AFTER the

  Check(GraphBuilder.RenderFile(PWideChar(Filename), Nil));  // <--- Exception here!

line.
This makes no sense at all, since the exception would occur before the modification to 'filename'.

Anyway, I found the cause and it's quite sillly, actually.
I assumed the GraphBuilder.QueryInterface calls were successful, since they didn't return an error, but it seems the CoCreateInstance call returns a nil object and thereby rendering GraphBuilder totally invalid.

My conclution is that COM is too unreliable to use in Free Pascal, so I will be returning to Delphi ASAP.

Thanks again all!

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 6674
Re: Exception: SIGILL?
« Reply #7 on: February 02, 2010, 01:20:29 pm »
This makes no sense at all, since the exception would occur before the modification to 'filename'.

The unneeded modification might make sure that the filename string is kept alive till after the call.

Quote
Anyway, I found the cause and it's quite sillly, actually.
I assumed the GraphBuilder.QueryInterface calls were successful, since they didn't return an error, but it seems the CoCreateInstance call returns a nil object and thereby rendering GraphBuilder totally invalid.

My conclution is that COM is too unreliable to use in Free Pascal, so I will be returning to Delphi ASAP.

Thanks again all!

For COM support it is advised to work with at least 2.5.1. In fall several things were fixed and expanded which are not in 2.4.0

Jonas Maebe

  • Hero Member
  • *****
  • Posts: 588
Re: Exception: SIGILL?
« Reply #8 on: February 02, 2010, 02:40:34 pm »
This makes no sense at all, since the exception would occur before the modification to 'filename'.

The unneeded modification might make sure that the filename string is kept alive till after the call.

String variables are always live. Problems with reference counts related to typecasting an ansistring to pchar or a widestring to pwidechar only occur in case this is done to temporary expressions (such as the value returned by a function). In such case, you have to assign the function result first to a variable/field, and then typecast said variable/field.

Adding an empty string to another string will not do anything under any circumstances (it won't even make the string unique in case it is reference counted).

SirLucifer

  • New member
  • *
  • Posts: 18
Re: Exception: SIGILL?
« Reply #9 on: February 02, 2010, 03:13:29 pm »
Quote
The unneeded modification might make sure that the filename string is kept alive till after the call.
Since the Filename local variable is only used in this case, for loading, it's essentially useless after the call, so if there was a referencecount issue, I would have used UniqueString or equivalent.

Trying 2.5.1 or whatever is the latest at this time.