Bug hunting

[ovhpa]

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,

[ovhpa]

Here are the statistics of the correction I made on clang bugs (total 152 bugs):

• Dead store
  • Dead assignment 84
  • Dead increment 2

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 ;)

• Logic error
  • Assigned value is garbage or undefined 7
  • Branch condition evaluates to a garbage value 1
  • Dereference of null pointer 11
  • Dereference of undefined pointer value 6
  • Result of operation is garbage or undefined 5
  • Uninitialized argument value 9

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.

• Memory error
  Memory leak 22
  Use of zero allocated 3
  Use-after-free 2

These where actually mostly some memory cleaning bugs (missing g_free).

[ovhpa]

PS: In case some problem appear, there is a number on each bug report that I can use to see exactly what went wrong.

[arohl]

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...

[ovhpa]

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?

[arohl]

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/gui_edit-c31f20.sh clang: note: diagnostic msg: Crash backtrace is located in clang: note: diagnostic msg: /Users/andrew/Library/Logs/DiagnosticReports/clang_<YYYY-MM-DD-HHMMSS>_<hostname>.crash clang: note: diagnostic msg: (choose the .crash file that corresponds to your crash) clang: note: diagnostic msg: 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 GitHub<#19 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AKebLD-11DvOJgEoTnNilXmLPcQBTkXzks5vFUS-gaJpZM4aJGYF>.

[ovhpa]

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.

[arohl]

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.au<mailto:andrew.rohl@curtin.edu.au> Web | computation.curtin.edu.au<https://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 GitHub<#19 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AKebLFF1rVyBMmNFkp8IgjH_HJWU4NG1ks5vFVgXgaJpZM4aJGYF>.