CodeAi (https://github.com/C0deAi), an automated repair tool developed at QbitLogic (www.qbitlogic.com), suggested the following fix. Could I submit it as a patch if it looks alright?
plugins/saveactions.c: “doc->file_type” pointer might be dereferenced when null on line 283. Initialization may be provided by “doc” passed in as a function argument, but a null check would be prudent just in case. The fix checks “doc->file_type” for null before allowing a dereference on the following line. A snapshot of the bug report generated by CodeAi is attached. A full report is available upon request.
diff --git a/plugins/saveactions.c b/plugins/saveactions.c
@@ -280,8 +280,10 @@ static void instantsave_document_new_cb(GObject *obj, GeanyDocument *doc, gpoint
doc->file_name = new_filename;
- if (doc->file_type->id == GEANY_FILETYPES_NONE)
+ if(doc->file_type) {
+ if (doc->file_type->id == GEANY_FILETYPES_NONE)
document_set_filetype(doc, filetypes_lookup_by_name(instantsave_default_ft));
+ }
/* force saving the file to enable all the related actions(tab name, filetype, etc.) */
document_save_file(doc, TRUE);
/* force saving the file to enable all the related actions(tab name, filetype, etc.) */
document_save_file(doc, TRUE);
}
}
Base-commit: 84253714771f48dbc7fab02f7de43f253734dee2
Please let me know if you are interested in seeing more fixes from our tool. Thanks!
Sincerely,
On 11 May 2017 at 08:10, Benjamin Bales benjamin.bales@qbitlogic.com wrote:
CodeAi (https://github.com/C0deAi), an automated repair tool developed at QbitLogic (www.qbitlogic.com), suggested the following fix. Could I submit it as a patch if it looks alright?
plugins/saveactions.c: “doc->file_type” pointer might be dereferenced when null on line 283. Initialization may be provided by “doc” passed in as a function argument, but a null check would be prudent just in case. The fix checks “doc->file_type” for null before allowing a dereference on the following line. A snapshot of the bug report generated by CodeAi is attached. A full report is available upon request.
This function is called (via the signal framework) by the function that created `doc` and as such cannot be null. The design of the application uses the signal framework to decouple caller and callee and this is likely to confuse your tool since it cannot see where functions are called. Whilst any contributions are welcome, a report with a lot of similar false positives may end up being ignored and be a bad advertisement for your tool.
Cheers Lex
diff --git a/plugins/saveactions.c b/plugins/saveactions.c
@@ -280,8 +280,10 @@ static void instantsave_document_new_cb(GObject *obj, GeanyDocument *doc, gpoint
doc->file_name = new_filename;
- if (doc->file_type->id == GEANY_FILETYPES_NONE)
if(doc->file_type) {
if (doc->file_type->id == GEANY_FILETYPES_NONE)
document_set_filetype(doc, filetypes_lookup_by_name(
instantsave_default_ft));
}
/* force saving the file to enable all the related actions(tab name,
filetype, etc.) */
document_save_file(doc, TRUE);
/* force saving the file to enable all the related actions(tab name, filetype, etc.) */
document_save_file(doc, TRUE);
}}
Base-commit: 84253714771f48dbc7fab02f7de43f253734dee2
Please let me know if you are interested in seeing more fixes from our tool. Thanks!
Sincerely,
Benjamin Bales Chief Technology Officer [image: QbitLogic] 1050 Crown Pointe Pkwy, Ste. 840 Atlanta, GA 30338 470-554-2690
CONFIDENTIALITY NOTICE
This e-mail and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to which they are addressed. This communication may contain privileged attorney material or other Property and Confidential matter. If you are not the intended recipient or the person responsible for delivering the e-mail for the intended person, be advised that you have received this e-mail in error and that any use, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you believe you have received this e-mail in error, please immediately delete this e-mail and notify Benjamin Bales by telephoning 470-554-2690.
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On 2017-05-10 04:09 PM, Lex Trotman wrote:
On 11 May 2017 at 08:10, Benjamin Bales benjamin.bales@qbitlogic.com wrote:
CodeAi (https://github.com/C0deAi), an automated repair tool developed at QbitLogic (www.qbitlogic.com), suggested the following fix. Could I submit it as a patch if it looks alright?
plugins/saveactions.c: “doc->file_type” pointer might be dereferenced when null on line 283. Initialization may be provided by “doc” passed in as a function argument, but a null check would be prudent just in case. The fix checks “doc->file_type” for null before allowing a dereference on the following line. A snapshot of the bug report generated by CodeAi is attached. A full report is available upon request.
This function is called (via the signal framework) by the function that created `doc` and as such cannot be null. The design of the application uses the signal framework to decouple caller and callee and this is likely to confuse your tool since it cannot see where functions are called. Whilst any contributions are welcome, a report with a lot of similar false positives may end up being ignored and be a bad advertisement for your tool.
Naw, I think it's technically a real bug, albeit very minor. It's the `file_type` member of the `doc` that can be NULL. IIUC tools like this look to see if you checked the NULL-ness of something and then proceed to dereference it outside of that check later, which this code does (checks if `ft == NULL` several lines up and then unconditionally dereferences it on the line given by the OP).
Regards, Matthew Brush
Lex and Matthew,
You seem to disagree on this issue. Is this a valid issue? And if so, do you like the fix? I can batch a few of them (<= 10) as a single PR. No problem.
-Ben
On Wed, May 10, 2017 at 8:22 PM, Matthew Brush mbrush@codebrainz.ca wrote:
On 2017-05-10 04:09 PM, Lex Trotman wrote:
On 11 May 2017 at 08:10, Benjamin Bales benjamin.bales@qbitlogic.com wrote:
CodeAi (https://github.com/C0deAi), an automated repair tool developed at
QbitLogic (www.qbitlogic.com), suggested the following fix. Could I submit it as a patch if it looks alright?
plugins/saveactions.c: “doc->file_type” pointer might be dereferenced when null on line 283. Initialization may be provided by “doc” passed in as a function argument, but a null check would be prudent just in case. The fix checks “doc->file_type” for null before allowing a dereference on the following line. A snapshot of the bug report generated by CodeAi is attached. A full report is available upon request.
This function is called (via the signal framework) by the function that created `doc` and as such cannot be null. The design of the application uses the signal framework to decouple caller and callee and this is likely to confuse your tool since it cannot see where functions are called. Whilst any contributions are welcome, a report with a lot of similar false positives may end up being ignored and be a bad advertisement for your tool.
Naw, I think it's technically a real bug, albeit very minor. It's the `file_type` member of the `doc` that can be NULL. IIUC tools like this look to see if you checked the NULL-ness of something and then proceed to dereference it outside of that check later, which this code does (checks if `ft == NULL` several lines up and then unconditionally dereferences it on the line given by the OP).
Regards, Matthew Brush
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On 2017-05-11 12:40 PM, Benjamin Bales wrote:
Lex and Matthew,
You seem to disagree on this issue. Is this a valid issue? And if so, do you like the fix? I can batch a few of them (<= 10) as a single PR. No problem.
If they're valid bugs (even minor), it certainly doesn't hurt to make a PR (or even an Issue just giving the info). They'll probably require more than an automated fix though, to account for formatting/indentation as well as looking at how it affects the code. Likely they'll need a human to evaluate what the correct fix is, for example the one given before is probably not very good as it just guards out code that was expected to run, rather than figuring out how the code was meant to work and make it do that.
Regards, Matthew Brush
-Ben
On Wed, May 10, 2017 at 8:22 PM, Matthew Brush mbrush@codebrainz.ca wrote:
On 2017-05-10 04:09 PM, Lex Trotman wrote:
On 11 May 2017 at 08:10, Benjamin Bales benjamin.bales@qbitlogic.com wrote:
CodeAi (https://github.com/C0deAi), an automated repair tool developed at
QbitLogic (www.qbitlogic.com), suggested the following fix. Could I submit it as a patch if it looks alright?
plugins/saveactions.c: “doc->file_type” pointer might be dereferenced when null on line 283. Initialization may be provided by “doc” passed in as a function argument, but a null check would be prudent just in case. The fix checks “doc->file_type” for null before allowing a dereference on the following line. A snapshot of the bug report generated by CodeAi is attached. A full report is available upon request.
This function is called (via the signal framework) by the function that created `doc` and as such cannot be null. The design of the application uses the signal framework to decouple caller and callee and this is likely to confuse your tool since it cannot see where functions are called. Whilst any contributions are welcome, a report with a lot of similar false positives may end up being ignored and be a bad advertisement for your tool.
Naw, I think it's technically a real bug, albeit very minor. It's the `file_type` member of the `doc` that can be NULL. IIUC tools like this look to see if you checked the NULL-ness of something and then proceed to dereference it outside of that check later, which this code does (checks if `ft == NULL` several lines up and then unconditionally dereferences it on the line given by the OP).
Regards, Matthew Brush
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
ok, I'll submit a PR with some of the fixes that I think are good. Was the format of the bug report acceptable? Our tool integrates with static analyzers, and sometimes its tricky to include their reports in a way that is clear and concise. Of course, I will provide my own summary of the issues, but I would like to know if you found them helpful.
-Ben
On Thu, May 11, 2017 at 4:24 PM, Matthew Brush mbrush@codebrainz.ca wrote:
On 2017-05-11 12:40 PM, Benjamin Bales wrote:
Lex and Matthew,
You seem to disagree on this issue. Is this a valid issue? And if so, do you like the fix? I can batch a few of them (<= 10) as a single PR. No problem.
If they're valid bugs (even minor), it certainly doesn't hurt to make a PR (or even an Issue just giving the info). They'll probably require more than an automated fix though, to account for formatting/indentation as well as looking at how it affects the code. Likely they'll need a human to evaluate what the correct fix is, for example the one given before is probably not very good as it just guards out code that was expected to run, rather than figuring out how the code was meant to work and make it do that.
Regards, Matthew Brush
-Ben
On Wed, May 10, 2017 at 8:22 PM, Matthew Brush mbrush@codebrainz.ca wrote:
On 2017-05-10 04:09 PM, Lex Trotman wrote:
On 11 May 2017 at 08:10, Benjamin Bales benjamin.bales@qbitlogic.com
wrote:
CodeAi (https://github.com/C0deAi), an automated repair tool developed at
QbitLogic (www.qbitlogic.com), suggested the following fix. Could I submit it as a patch if it looks alright?
plugins/saveactions.c: “doc->file_type” pointer might be dereferenced when null on line 283. Initialization may be provided by “doc” passed in as a function argument, but a null check would be prudent just in case. The fix checks “doc->file_type” for null before allowing a dereference on the following line. A snapshot of the bug report generated by CodeAi is attached. A full report is available upon request.
This function is called (via the signal framework) by the function that
created `doc` and as such cannot be null. The design of the application uses the signal framework to decouple caller and callee and this is likely to confuse your tool since it cannot see where functions are called. Whilst any contributions are welcome, a report with a lot of similar false positives may end up being ignored and be a bad advertisement for your tool.
Naw, I think it's technically a real bug, albeit very minor. It's the
`file_type` member of the `doc` that can be NULL. IIUC tools like this look to see if you checked the NULL-ness of something and then proceed to dereference it outside of that check later, which this code does (checks if `ft == NULL` several lines up and then unconditionally dereferences it on the line given by the OP).
Regards, Matthew Brush
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On 2017-05-11 01:34 PM, Benjamin Bales wrote:
ok, I'll submit a PR with some of the fixes that I think are good. Was the format of the bug report acceptable? Our tool integrates with static analyzers, and sometimes its tricky to include their reports in a way that is clear and concise. Of course, I will provide my own summary of the issues, but I would like to know if you found them helpful.
It seems OK, though I just looked for the file/line info and studied what the code did, I didn't notice the PNG attachment until afterward. It reminds me a bit of clang static analyzer html/xcode output but without the fancy arrows.
Regards, Matthew Brush
yep. That's one of the analyzers we integrate with. We're expanding out portfolio to include a suite of open source and (1 or 2) proprietary static analyzers. They help to identify defects and provide information about the defect to our AI (deep learning) component that suggests fixes. Obviously its a work in progress, but if we can help people out now, that would be awesome!
In the PR, I'll supply the BR from the static analyzer upon request.
On Thu, May 11, 2017 at 5:00 PM, Matthew Brush mbrush@codebrainz.ca wrote:
On 2017-05-11 01:34 PM, Benjamin Bales wrote:
ok, I'll submit a PR with some of the fixes that I think are good. Was the format of the bug report acceptable? Our tool integrates with static analyzers, and sometimes its tricky to include their reports in a way that is clear and concise. Of course, I will provide my own summary of the issues, but I would like to know if you found them helpful.
It seems OK, though I just looked for the file/line info and studied what the code did, I didn't notice the PNG attachment until afterward. It reminds me a bit of clang static analyzer html/xcode output but without the fancy arrows.
Regards, Matthew Brush _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Am 2017-05-11 22:34, schrieb Benjamin Bales:
ok, I'll submit a PR with some of the fixes that I think are good. Was the format of the bug report acceptable? Our tool integrates with static analyzers, and sometimes its tricky to include their reports in a way that is clear and concise. Of course, I will provide my own summary of the issues, but I would like to know if you found them helpful.
IMHO you should not send fancy formatted mails like this. Never ever. Plaintext. It's proper readable on every client in special when it's such a technical subject.
Beside of the format I'm afraid I did not check the content too carefully (as the format did also block me from fast reading).
Cheers, Frank
I apologize for that. Here's the report in plain text format:
CodeAi (https://github.com/C0deAi), an automated repair tool developed at QbitLogic (www.qbitlogic.com), suggested the following fix. Could I submit it as a patch if it looks alright?
plugins/saveactions.c: “doc->file_type” pointer might be dereferenced when null on line 283. Initialization may be provided by “doc” passed in as a function argument, but a null check would be prudent just in case. The fix checks “doc->file_type” for null before allowing a dereference on the following line. A snapshot of the bug report generated by CodeAi is attached. A full report is available upon request.
diff --git a/plugins/saveactions.c b/plugins/saveactions.c @@ -280,8 +280,10 @@ static void instantsave_document_new_cb(GObject *obj, GeanyDocument *doc, gpoint doc->file_name = new_filename; - if (doc->file_type->id == GEANY_FILETYPES_NONE) + if(doc->file_type) { + if (doc->file_type->id == GEANY_FILETYPES_NONE) document_set_filetype(doc, filetypes_lookup_by_name(instantsave_default_ft)); + } /* force saving the file to enable all the related actions(tab name, filetype, etc.) */ document_save_file(doc, TRUE);
Base-commit: 84253714771f48dbc7fab02f7de43f253734dee2
Please let me know if you are interested in seeing more fixes from our tool. Thanks!
Sincerely, Benjamin Bales CTO QbitLogic
On Fri, May 12, 2017 at 2:53 AM, Frank Lanitz frank@frank.uvena.de wrote:
Am 2017-05-11 22:34, schrieb Benjamin Bales:
ok, I'll submit a PR with some of the fixes that I think are good. Was the format of the bug report acceptable? Our tool integrates with static analyzers, and sometimes its tricky to include their reports in a way that is clear and concise. Of course, I will provide my own summary of the issues, but I would like to know if you found them helpful.
IMHO you should not send fancy formatted mails like this. Never ever. Plaintext. It's proper readable on every client in special when it's such a technical subject.
Beside of the format I'm afraid I did not check the content too carefully (as the format did also block me from fast reading).
Cheers, Frank
On 13 May 2017 at 03:44, Benjamin Bales benjamin.bales@qbitlogic.com wrote:
I apologize for that. Here's the report in plain text format:
CodeAi (https://github.com/C0deAi), an automated repair tool developed at QbitLogic (www.qbitlogic.com), suggested the following fix. Could I submit it as a patch if it looks alright?
plugins/saveactions.c: “doc->file_type” pointer might be dereferenced when null on line 283. Initialization may be provided by “doc” passed in as a function argument, but a null check would be prudent just in case. The fix checks “doc->file_type” for null before allowing a dereference on the following line. A snapshot of the bug report generated by CodeAi is attached. A full report is available upon request.
diff --git a/plugins/saveactions.c b/plugins/saveactions.c @@ -280,8 +280,10 @@ static void instantsave_document_new_cb(GObject *obj, GeanyDocument *doc, gpoint doc->file_name = new_filename;
- if (doc->file_type->id == GEANY_FILETYPES_NONE)
- if(doc->file_type) {
- if (doc->file_type->id == GEANY_FILETYPES_NONE)
Actually thats the wrong fix, `document_set_filetype()` still needs to be called, it should be `if(doc->file_type == NULL || doc->file_type->id == GEANY_FILETYPES_NONE)` the same as line 272.
But actually a better fix would be just moving line 284 to after 275 and pass ft as the second argument, thus only calling `filetypes_lookup_by_name()` once and removing the suspect `if` altogether.
And actually the comment is likely wrong, file_type is no longer left NULL, its set to GEANY_FILETYPES_NONE if no filetype is set AFAICT, but that needs interfile tracing to document.c and filetypes.c and to find.
document_set_filetype(doc, filetypes_lookup_by_name(instantsave_default_ft));
- }
/* force saving the file to enable all the related actions(tab name, filetype, etc.) */ document_save_file(doc, TRUE);
Base-commit: 84253714771f48dbc7fab02f7de43f253734dee2
Please let me know if you are interested in seeing more fixes from our tool. Thanks!
Sincerely, Benjamin Bales CTO QbitLogic
On Fri, May 12, 2017 at 2:53 AM, Frank Lanitz frank@frank.uvena.de wrote:
Am 2017-05-11 22:34, schrieb Benjamin Bales:
ok, I'll submit a PR with some of the fixes that I think are good. Was the format of the bug report acceptable? Our tool integrates with static analyzers, and sometimes its tricky to include their reports in a way that is clear and concise. Of course, I will provide my own summary of the issues, but I would like to know if you found them helpful.
IMHO you should not send fancy formatted mails like this. Never ever. Plaintext. It's proper readable on every client in special when it's such a technical subject.
Beside of the format I'm afraid I did not check the content too carefully (as the format did also block me from fast reading).
Cheers, Frank
-- Benjamin Bales Chief Technology Officer
1050 Crown Pointe Pkwy, Ste. 840 Atlanta, GA 30338 470-554-2690
CONFIDENTIALITY NOTICE
This e-mail and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to which they are addressed. This communication may contain privileged attorney material or other Property and Confidential matter. If you are not the intended recipient or the person responsible for delivering the e-mail for the intended person, be advised that you have received this e-mail in error and that any use, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you believe you have received this e-mail in error, please immediately delete this e-mail and notify Benjamin Bales by telephoning 470-554-2690.
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On 05/12/2017 07:44 PM, Benjamin Bales wrote:
I apologize for that. Here's the report in plain text format:
No need to apologize here. I completely agree with Frank regarding plain text emails are better than fancy HTML pages in an email in general and on mailing lists in special.
But your first mail was sent as plain text as well as HTML and this is perfectly fine. My mail client displayed the mail as plain text properly (as it is configured to prefer plain text variants of mails if they contain both).
Just my 2 cents.
Regards, Enrico
On 12 May 2017 at 05:40, Benjamin Bales benjamin.bales@qbitlogic.com wrote:
Lex and Matthew,
You seem to disagree on this issue. Is this a valid issue? And if so, do you like the fix? I can batch a few of them (<= 10) as a single PR. No problem.
Matthew is right, I misread the report as saying that `doc` was possibly NULL, not `file_name`. At the moment the project members are having a crisis of availability, so at the moment smaller is better. Checking a single one quickly is more likely to fit into someones day.
Cheers Lex
-Ben
On Wed, May 10, 2017 at 8:22 PM, Matthew Brush mbrush@codebrainz.ca wrote:
On 2017-05-10 04:09 PM, Lex Trotman wrote:
On 11 May 2017 at 08:10, Benjamin Bales benjamin.bales@qbitlogic.com wrote:
CodeAi (https://github.com/C0deAi), an automated repair tool developed
at QbitLogic (www.qbitlogic.com), suggested the following fix. Could I submit it as a patch if it looks alright?
plugins/saveactions.c: “doc->file_type” pointer might be dereferenced when null on line 283. Initialization may be provided by “doc” passed in as a function argument, but a null check would be prudent just in case. The fix checks “doc->file_type” for null before allowing a dereference on the following line. A snapshot of the bug report generated by CodeAi is attached. A full report is available upon request.
This function is called (via the signal framework) by the function that created `doc` and as such cannot be null. The design of the application uses the signal framework to decouple caller and callee and this is likely to confuse your tool since it cannot see where functions are called. Whilst any contributions are welcome, a report with a lot of similar false positives may end up being ignored and be a bad advertisement for your tool.
Naw, I think it's technically a real bug, albeit very minor. It's the `file_type` member of the `doc` that can be NULL. IIUC tools like this look to see if you checked the NULL-ness of something and then proceed to dereference it outside of that check later, which this code does (checks if `ft == NULL` several lines up and then unconditionally dereferences it on the line given by the OP).
Regards, Matthew Brush
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
-- Benjamin Bales Chief Technology Officer [image: QbitLogic] 1050 Crown Pointe Pkwy, Ste. 840 Atlanta, GA 30338 470-554-2690
CONFIDENTIALITY NOTICE
This e-mail and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to which they are addressed. This communication may contain privileged attorney material or other Property and Confidential matter. If you are not the intended recipient or the person responsible for delivering the e-mail for the intended person, be advised that you have received this e-mail in error and that any use, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you believe you have received this e-mail in error, please immediately delete this e-mail and notify Benjamin Bales by telephoning 470-554-2690.
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On 2017-05-10 03:10 PM, Benjamin Bales wrote:
CodeAi (https://github.com/C0deAi), an automated repair tool developed at QbitLogic (www.qbitlogic.com), suggested the following fix. Could I submit it as a patch if it looks alright?
plugins/saveactions.c: “doc->file_type” pointer might be dereferenced when null on line 283. Initialization may be provided by “doc” passed in as a function argument, but a null check would be prudent just in case. The fix checks “doc->file_type” for null before allowing a dereference on the following line. A snapshot of the bug report generated by CodeAi is attached. A full report is available upon request.
diff --git a/plugins/saveactions.c b/plugins/saveactions.c
@@ -280,8 +280,10 @@ static void instantsave_document_new_cb(GObject *obj, GeanyDocument *doc, gpoint
doc->file_name = new_filename;
- if (doc->file_type->id == GEANY_FILETYPES_NONE)
if(doc->file_type) {
if (doc->file_type->id == GEANY_FILETYPES_NONE)
document_set_filetype(doc,
filetypes_lookup_by_name(instantsave_default_ft));
}
/* force saving the file to enable all the related actions(tab name,
filetype, etc.) */
document_save_file(doc, TRUE);
/* force saving the file to enable all the related actions(tab name, filetype, etc.) */
document_save_file(doc, TRUE);
}}
Base-commit: 84253714771f48dbc7fab02f7de43f253734dee2
Please let me know if you are interested in seeing more fixes from our tool. Thanks!
Hi,
You can submit pull requests with properly formatted changes on Github. We've had a few PRs like these where analysis tools were run over the codebase and found issues (ex. see PR #166 & #186). If there are multiple trivial changes, it's probably fine to put it all in one PR as separate commits.
Regards, Matthew Brush
