Closed ovhpa closed 5 years ago
Here are the statistics of the correction I made on clang bugs (total 152 bugs):
Most of these bugs are unimportant such as:
//some code
i=0;/*i is set but lost as the next instruction re-set it*/
for(i=0;i<N;i++){
//some code
or places where some value is set but never read:
void function(){
int i;
//some code
i=0;/*i is set but lost as the function return*/
return;
}
Even though there is no gain in removing them, I did it for the clean-up ;)
Some of these bugs have require quite some change but in most cases they resolve to an unprobable case in which someone is trying to feed corrupt or unrelated data into a function.
These where actually mostly some memory cleaning bugs (missing g_free).
PS: In case some problem appear, there is a number on each bug report that I can use to see exactly what went wrong.
Oddly the compile on my Mac crashes if I use clang via the makefile but is OK if I compile in Xcode (which uses clang) or use gcc...
I used clang static analysis tool on a gcc
build by running:
scan-build -v make -j
while using a makefile.linux containing only gcc
.
It's strange but the build using clang
also fails for me (on file gui_edit.c
).
I will investigate a little more on that issue...
It seems that gui_edit.c (and GDIS) can be compiled by clang
:
clang -Wall -O0 -DWITH_GUI -c gui_edit.c `pkg-config --cflags gtk+-2.0 gthread-2.0 gtkglext-1.0 gmodule-2.0`
but will fail if any optimization level is used:
clang -Wall -O1 -DWITH_GUI -c gui_edit.c `pkg-config --cflags gtk+-2.0 gthread-2.0 gtkglext-1.0 gmodule-2.0`
clang-6.0: error: unable to execute command: Segmentation fault (core dumped)
clang-6.0: error: clang frontend command failed due to signal (use -v to see invocation)
Can you confirm?
Confirmed
clang -Wall -O0 -DWITH_GUI -c gui_edit.c pkg-config --cflags gtk+-2.0 gthread-2.0 gtkglext-1.0 gmodule-2.0
clang -Wall -O1 -DWITH_GUI -c gui_edit.c pkg-config --cflags gtk+-2.0 gthread-2.0 gtkglext-1.0 gmodule-2.0
clang: error: unable to execute command: Segmentation fault: 11
clang: error: clang frontend command failed due to signal (use -v to see invocation)
Apple LLVM version 10.0.0 (clang-1000.11.45.5)
Target: x86_64-apple-darwin18.2.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script.
clang: note: diagnostic msg:
PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg: /var/folders/rd/b7mwqr5531xch_1nbl2v_s600000gn/T/gui_edit-c31f20.c
clang: note: diagnostic msg: /var/folders/rd/b7mwqr5531xch_1nbl2v_s600000gn/T/guiedit-c31f20.sh
clang: note: diagnostic msg: Crash backtrace is located in
clang: note: diagnostic msg: /Users/andrew/Library/Logs/DiagnosticReports/clang
On 21 Jan 2019, at 12:40 pm, Okadome Valencia notifications@github.com<mailto:notifications@github.com> wrote:
I used clang static analysis tool on a gcc build by running:
scan-build -v make -j
while using a makefile.linux containing only gcc.
It's strange but the build using clang also fails for me (on file gui_edit.c). I will investigate a little more on that issue... It seems that gui_edit.c (and GDIS) can be compiled by clang:
clang -Wall -O0 -DWITH_GUI -c gui_edit.c pkg-config --cflags gtk+-2.0 gthread-2.0 gtkglext-1.0 gmodule-2.0
but will fail if any optimization level is used:
clang -Wall -O1 -DWITH_GUI -c gui_edit.c pkg-config --cflags gtk+-2.0 gthread-2.0 gtkglext-1.0 gmodule-2.0
clang-6.0: error: unable to execute command: Segmentation fault (core dumped)
clang-6.0: error: clang frontend command failed due to signal (use -v to see invocation)
Can you confirm?
— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHubhttps://github.com/arohl/gdis/pull/19#issuecomment-455946423, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AKebLD-11DvOJgEoTnNilXmLPcQBTkXzks5vFUS-gaJpZM4aJGYF.
Thank you for confirming.
I will try to look after this bug in this week. If it's not too big, can you send me the corresponding .crash file by PM?
I think it would be nice if we can have clang to generate GDIS, in addition to gcc.
Its tiny
Professor Andrew Rohl DPhil FACS Director | ARC Training Centre for Transforming Maintenance through Data Science Director | Curtin Institute for Computation Chemistry | School of Molecular and Life Sciences
Curtin University Tel | +61 8 9266 3124 Fax | +61 8 9266 2300 Mobile | 0401 103 620
Email | andrew.rohl@curtin.edu.aumailto:andrew.rohl@curtin.edu.au Web | computation.curtin.edu.auhttps://computation.curtin.edu.au
CRICOS Provider Code 00301J
On 21 Jan 2019, at 2:03 pm, Okadome Valencia notifications@github.com<mailto:notifications@github.com> wrote:
Thank you for confirming.
I will try to look after this bug in this week. If it's not too big, can you send me the corresponding .crash file by PM?
I think it would be nice if we can have clang to generate GDIS, in addition to gcc.
— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHubhttps://github.com/arohl/gdis/pull/19#issuecomment-455957819, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AKebLFF1rVyBMmNFkp8IgjH_HJWU4NG1ks5vFVgXgaJpZM4aJGYF.
Dear Prof. Rohl,
I have recently been using clang static analysis tool to remove some bugs. Even though most of these bugs didn't affect the normal operation of GDIS, I feel there have been some improvement in stability and speed after that (but that might actually be only my imagination).
Sincerely,