After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 611603 - add more assertions to gjs_invoke_c_function
add more assertions to gjs_invoke_c_function
Status: RESOLVED FIXED
Product: gjs
Classification: Bindings
Component: general
unspecified
Other All
: Normal normal
: ---
Assigned To: gjs-maint
gjs-maint
Depends on:
Blocks: 612967
 
 
Reported: 2010-03-02 14:37 UTC by Tommi Komulainen
Modified: 2016-11-29 07:33 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
gi: make it more clear only processed_in_args are being released (1.31 KB, patch)
2010-03-02 14:37 UTC, Tommi Komulainen
committed Details | Review
gi: assert we don't access argv out of bounds (1.89 KB, patch)
2010-03-02 14:37 UTC, Tommi Komulainen
committed Details | Review
gi: assert all arguments are processed prior to invoking the function (1.01 KB, patch)
2010-03-02 14:37 UTC, Tommi Komulainen
committed Details | Review
gi: assert all arguments were released after invoking the function (1.85 KB, patch)
2010-03-02 14:37 UTC, Tommi Komulainen
committed Details | Review
remove incorrect asserts in function.c (848 bytes, patch)
2010-03-18 03:23 UTC, Maxim Ermilov
committed Details | Review

Description Tommi Komulainen 2010-03-02 14:37:26 UTC
Mainly for reassurance that we loop over the multiple arguments arrays as
expected, not going out of bounds or leaving anything out.
Comment 1 Tommi Komulainen 2010-03-02 14:37:28 UTC
Created attachment 155040 [details] [review]
gi: make it more clear only processed_in_args are being released

If the loop ends "prematurely" because of processed_in_args then the
invoke had failed and INOUT/OUT arguments wouldn't be handled anyway so
there's no point in continuing with the loop.
Comment 2 Tommi Komulainen 2010-03-02 14:37:33 UTC
Created attachment 155041 [details] [review]
gi: assert we don't access argv out of bounds

Helps avoid bugs that might otherwise silently creep in.
Comment 3 Tommi Komulainen 2010-03-02 14:37:39 UTC
Created attachment 155042 [details] [review]
gi: assert all arguments are processed prior to invoking the function
Comment 4 Tommi Komulainen 2010-03-02 14:37:48 UTC
Created attachment 155043 [details] [review]
gi: assert all arguments were released after invoking the function

Or at least assert the array indexes are as expected after iterating
through the arguments.
Comment 5 Johan (not receiving bugmail) Dahlin 2010-03-02 16:48:54 UTC
Review of attachment 155043 [details] [review]:

Yes
Comment 6 Johan (not receiving bugmail) Dahlin 2010-03-02 16:49:04 UTC
Review of attachment 155042 [details] [review]:

Yes
Comment 7 Johan (not receiving bugmail) Dahlin 2010-03-02 16:49:08 UTC
Review of attachment 155041 [details] [review]:

Yes
Comment 8 Johan (not receiving bugmail) Dahlin 2010-03-02 16:49:12 UTC
Review of attachment 155040 [details] [review]:

Yes
Comment 9 Florian Müllner 2010-03-17 10:27:37 UTC
Attachment 155040 [details] pushed as c37384d - gi: make it more clear only processed_in_args are being released
Attachment 155041 [details] pushed as 29bc446 - gi: assert we don't access argv out of bounds
Attachment 155042 [details] pushed as 2a5dbdb - gi: assert all arguments are processed prior to invoking the function
Attachment 155043 [details] pushed as 7d572c6 - gi: assert all arguments were released after invoking the function

Any reason for leaving the bug open?
Comment 10 Tommi Komulainen 2010-03-17 10:44:29 UTC
No reason, thanks for noticing.
Comment 11 Maxim Ermilov 2010-03-18 03:23:41 UTC
Created attachment 156428 [details] [review]
remove incorrect asserts in function.c

For example Gdk.Screen.get_default().get_root_window().get_pointer can return unknown mask(It will throw error arg.c:56). It is a normal situation.
Comment 12 Tommi Komulainen 2010-03-18 10:27:07 UTC
Review of attachment 156428 [details] [review]:

This is good, though could use a test that would trigger the assertion. A call with incorrect argument seems to do the trick which was not intended.

I would also prefer some assertions also for the error cases to make sure we dealt with all the arguments as we're supposed to.
Comment 13 Philip Chimento 2016-11-29 07:33:28 UTC
All patches seem to have been committed.