2.4. 用 cc 來編譯程式

當使用 sin() 這類的數學函示時， 你必須告訴 cc 要和數學函式庫作連結(linking)，就像這樣：

% cc -o foobar foobar.c -lm
	     

當編譯器發現你呼叫一個函示時，它會確認該函示的回傳值類型(prototype)， 如果沒有特別指明，則預設的回傳值類型為 int(整數)。 很明顯的，你的程式所需要的並不是回傳值類別為 int。

數學函示的回傳值類型(prototype)會定義在 math.h， 如果你有 include 這檔，編譯器就會知道該函示的回傳值類型，如此一來該運算就會得到正確的結果！

#include <math.h>
#include <stdio.h>

int main() {
...
	     

加了上述內容之後，再重新編譯，最後執行：

% ./a.out
2.1 ^ 6 = 85.766121
	     

如果有用到數學函式，請確定要有 include math.h 這檔， 而且記得要和數學函式庫作連結。

記得，除非有指定編譯結果的執行檔檔名，否則預設的執行檔檔名是 a.out。 用 -o filename 參數， 就可以達到所想要的結果，比如：

% cc -o foobar foobar.c
	     

與 MS-DOS 不同的是，除非有指定執行檔的路徑， 否則 UNIX 系統並不會在目前的目錄下尋找你想執行的檔案。 在指令列下打 ./foobar 代表 “執行在這個目錄底下名為 foobar 的程式”， 或者也可以更改 PATH 環境變數設定如下，以達成類似效果：

bin:/usr/bin:/usr/local/bin:.
	     

上一行最後的 "." 代表“如果在前面寫的其他目錄找不到，就找目前的目錄”。

大多數的 UNIX 系統都會在路徑 /usr/bin 擺放執行檔。 除非有指定使用在目前目錄內的 test，否則 shell 會優先選擇位在 /usr/bin 的 test， 要指定檔名的話，作法類似：

% ./test
	     

為了避免上述困擾，請為你的程式取更好的名稱吧！

關於 core dumped 這個名稱的由來， 可以追溯到早期的 UNIX 系統開始使用 core memory 對資料排序時。 基本上當程式在很多情況下發生錯誤後， 作業系統會把 core memory 中的資訊寫入 core 這檔案中， 以便讓 programmer 知道程式到底是為何出錯。

請用 gdb 來分析 core 結果(詳情請參考 µÚ 2.6 節)。

基本上，這個錯誤表示你的程式在記憶體中試著做一個嚴重的非法運作(illegal operation)， UNIX 就是被設計來保護整個作業系統免於被惡質的程式破壞，所以才會告訴你這個訊息。

最常造成“segmentation fault”的原因通常為：

• 試著對一個 NULL 的指標(pointer)作寫入的動作，如

  char *foo = NULL;
  strcpy(foo, "bang!");
  		
  

• 使用一個尚未初始化(initialized)的指標，如：

  char *foo;
  strcpy(foo, "bang!");
  		
  

  尚未初始化的指標的初始值將會是隨機的，如果你夠幸運的話， 這個指標的初始值會指向 kernel 已經用到的記憶體位置， kernel 會結束掉這個程式以確保系統運作正常。如果你不夠幸運， 初始指到的記憶體位置是你程式必須要用到的資料結構(data structures)的位置， 當這個情形發生時程式將會當的不知其所以然。

• 試著寫入超過陣列(array)元素個數，如：

  int bar[20];
  bar[27] = 6;
  		
  

• 試著讀寫在唯讀記憶體(read-only memory)中的資料，如：

  char *foo = "My string";
  strcpy(foo, "bang!");
  		
  

  UNIX compilers often put string literals like "My string" into read-only areas of memory.

• Doing naughty things with malloc() and free(), eg

  char bar[80];
  free(bar);
  		
  

  or

  char *foo = malloc(27);
  free(foo);
  free(foo);
  		
  

Making one of these mistakes will not always lead to an error, but they are always bad practice. Some systems and compilers are more tolerant than others, which is why programs that ran well on one system can crash when you try them on an another.

No, fortunately not (unless of course you really do have a hardware problem…). This is usually another way of saying that you accessed memory in a way you should not have.

Yes, just go to another console or xterm, do

% ps
	   

to find out the process ID of your program, and do

% kill -ABRT pid
	   

where pid is the process ID you looked up.

This is useful if your program has got stuck in an infinite loop, for instance. If your program happens to trap SIGABRT, there are several other signals which have a similar effect.

Alternatively, you can create a core dump from inside your program, by calling the abort() function. See the manual page of abort(3) to learn more.

If you want to create a core dump from outside your program, but do not want the process to terminate, you can use the gcore program. See the manual page of gcore(1) for more information.