Menu
▾
▴
[Swig-devel] Re: Want to revert some Ruby Error Message
|
From: Charlie S. <cf...@in...> - 2006-01-13 21:53:19
|
Hi Marcelo,
I took care of this by adding in a check for a null Ruby object. The
test case now passes, I'll verify the rest now.
Charlie
Marcelo Matus wrote:
> Thanks, that it was what I needed.
>
> It is fixed now.
>
> Marcelo
>
>
> Charlie Savage wrote:
>
>> Great. I've updated rubyerrors.swg to include support for
>> SWIG_NullReferenceError, since it did not handle that error.
>>
>> As far as the directors, the test cases don't compile on MinGW. Looks
>> to me that the issue is that struct Guard, and all its members, are
>> declared twice, once inside a #ifdef __PTHREAD__ and once outside. I
>> have removed the second declaration and checked in the code. Now on
>> MinGW all Ruby test cases pass.
>> Last, here is the issue with director_exception.rb. Ruby is returning
>> a rb_eRuntimeError instead of a rb_eTypeError, thus causing the
>> segmentation fault. Digging through the call stack, here is what is
>> going on:
>>
>> 1.std::string SwigDirector_Foo::ping() calls a Ruby object.ping .
>> Ping returns Qnil instead of string.
>>
>> 2. Around line 2140 in director_exception_wrap.cxx std::string
>> SwigDirector_Foo::ping() calls SWIG_AsPtr_std_string to check the result:
>>
>> int ores = SWIG_AsPtr_std_string(result, &optr);
>>
>> 3. First bug - SWIG_AsPtr_std_string decides Qnil is okay as a
>> string, which seems wrong. This happens because it doesn't check for
>> Qnil, and eventually ends up calling SWIG_Ruby_ConvertPtrAndOwn which
>> returns SWIG_OK for a null pointer, as it should.
>>
>> 4. Now back to std::string SwigDirector_Foo::ping():
>>
>> if (!SWIG_IsOK(ores) || !optr) {
>> Swig::DirectorTypeMismatchException::raise(SWIG_ErrorType(((ores !=
>> SWIG_ERROR) ? ores : SWIG_TypeError)), "in output value of type
>> '""std::string""'");
>> }
>>
>> ores is zero, so SWIG_IsOK returns false. Then SWIG_ErrorType gets
>> called with ores equal to zero, which means the exception by default
>> become rb_eRuntimeError. Thus the test blows up.
>>
>> Charlie
>>
>> Thanks,
>>
>> Charlie
>>
>> Marcelo Matus wrote:
>>
>>> Try it again.
>>>
>>> Now the result code is passed to %argfail or so.
>>>
>>> The only issue is that breaks the runtime example
>>> director_exception.rb. I have to debug that
>>> one tomorrow or so, or if you can take a look that will be great.
>>>
>>> in the offending case, it seems the error change from TypeError to
>>> RuntimeError after
>>> the change.
>>>
>>> Marcelo
>>>
>>>
>>> Charlie Savage wrote:
>>>
>>>> Hi Marcelo,
>>>>
>>>> Thanks for the suggestion. Unfortunately, it doesn't quite work.
>>>> The reason is that the calling method is:
>>>>
>>>>
>>>> if (!SWIG_IsOK((SWIG_ConvertPtr(self, &argp1,SWIGTYPE_p_Animal, 0
>>>> | 0 )))) {
>>>> SWIG_exception(SWIG_TypeError, "in method '" "$symname" "',
>>>> argument " "1"" of type '" "Animal const *""'");
>>>> }
>>>>
>>>> Thus it doesn't matter what error code SWIG_ConvertPtr returns, it
>>>> always gets turned into a SWIG_TypeError. It looks to me that the
>>>> error must be raised from SWIG_ConvertPtr.
>>>>
>>>> I noticed that SWIG_NullReferenceError is not checked for in
>>>> SWIG_Ruby_ErrorType so I'll add it in.
>>>>
>>>> Thanks,
>>>>
>>>> Charlie
>>>>
>>>> Marcelo Matus wrote:
>>>>
>>>>> You can use
>>>>>
>>>>>
>>>>> SWIG_Ruby_ConvertPtrAndOwn(...) {
>>>>> ...
>>>>> if (vptr == 0) {
>>>>> return SWIG_NullReferenceError;
>>>>> }
>>>>> }
>>>>>
>>>>> this is assuming you still can pass a null pointer to a function,
>>>>> right?, like in here:
>>>>>
>>>>> int foo(Bar *bar);
>>>>>
>>>>> You can also add another ruby code message, let say
>>>>>
>>>>> #define SWIG_RubyReleasedPtr -10000
>>>>>
>>>>> and dispatch that with SWIG_Ruby_ErrorType(code), since in your
>>>>> case vptr == 0
>>>>> doesn't mean a valid pointer with null value. Just be sure the
>>>>> error code is a negative
>>>>> value large enough to not interfere with the ones in swigerror.swg.
>>>>>
>>>>> Marcelo
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Charlie Savage wrote:
>>>>>
>>>>>> In the move to the unified type maps, some very useful Ruby error
>>>>>> messages were removed. I feel strongly they should be reinstated.
>>>>>>
>>>>>> For example, there is code to see if Ruby has freed an underlying
>>>>>> C++ object, and if so, to raise an error. This happens here:
>>>>>>
>>>>>> SWIG_Ruby_ConvertPtrAndOwn(...) {
>>>>>> ...
>>>>>> if (vptr == 0) {
>>>>>> return SWIG_ERROR
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> Note the error message is return SWIG_ERROR which is not very
>>>>>> helpful, especially for such a crucial error as this. Previously,
>>>>>> the error was:
>>>>>>
>>>>>> rb_raise(rb_eRuntimeError, "This %s already released", ty->str);
>>>>>>
>>>>>> This message makes it much clearer what has gone wrong, and thus
>>>>>> makes tracking down the problem easier.
>>>>>>
>>>>>> As a result, I would like to reinstate the old error message. I'd
>>>>>> be happy to do something like this:
>>>>>>
>>>>>> char buffer[512];
>>>>>> sprintf(buffer, "This object has already been released. Type:
>>>>>> %s", ty->str);
>>>>>> SWIG_Error(SWIG_NullReferenceError, buffer);
>>>>>>
>>>>>> However, this doesn't work because SWIG_ErrorType is defined like
>>>>>> this:
>>>>>>
>>>>>> #define SWIG_ERROR (-1)
>>>>>>
>>>>>> And then later, below SWIG_Ruby_ConvertPtrAndOwn as this:
>>>>>>
>>>>>> #define SWIG_Error(code, msg)
>>>>>> rb_raise(SWIG_Ruby_ErrorType(code), msg)
>>>>>>
>>>>>> Thus its easy to get this to work by using rb_raise directly (as
>>>>>> the old code did). Alternatively, to use SWIG_Error would require
>>>>>> messing around with ruby.swg/rubyruntime.swg/rubyerrors.swg to get
>>>>>> all the declarations lined up correctly. I'd argue this is
>>>>>> probably a good idea anyway but I'd guess this is probably more
>>>>>> difficult then it seems on the face of it.
>>>>>>
>>>>>> So, I'd like to get this changed for the upcoming release and
>>>>>> would be happy to do it assuming noone has any big issues with it.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Charlie
>>>>>>
>>>>>>
>>>>>>
>>>>>> -------------------------------------------------------
>>>>>> This SF.net email is sponsored by: Splunk Inc. Do you grep through
>>>>>> log files
>>>>>> for problems? Stop! Download the new AJAX search engine that makes
>>>>>> searching your log files as easy as surfing the web. DOWNLOAD
>>>>>> SPLUNK!
>>>>>> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
>>>>>> _______________________________________________
>>>>>> Swig-devel mailing list
>>>>>> Swi...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/swig-devel
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -------------------------------------------------------
>>>>> This SF.net email is sponsored by: Splunk Inc. Do you grep through
>>>>> log files
>>>>> for problems? Stop! Download the new AJAX search engine that makes
>>>>> searching your log files as easy as surfing the web. DOWNLOAD
>>>>> SPLUNK!
>>>>> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> -------------------------------------------------------
>>>> This SF.net email is sponsored by: Splunk Inc. Do you grep through
>>>> log files
>>>> for problems? Stop! Download the new AJAX search engine that makes
>>>> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
>>>> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
>>>> _______________________________________________
>>>> Swig-devel mailing list
>>>> Swi...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/swig-devel
>>>
>>>
>>>
>>>
>>>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
|