Thực hành tốt nhất về lập trình phòng thủ được yêu thích (thông minh)

Nếu bạn phải chọn các kỹ thuật yêu thích (thông minh) cho mã hóa phòng thủ, chúng sẽ là gì? Mặc dù các ngôn ngữ hiện tại của tôi là Java và Objective-C (có nền tảng về C ++), vui lòng trả lời bằng bất kỳ ngôn ngữ nào. Nhấn mạnh ở đây sẽ là về các kỹ thuật phòng thủ thông minh khác với những kỹ thuật mà 70% chúng ta ở đây đã biết. Vì vậy, bây giờ là thời gian để đào sâu vào túi thủ đoạn của bạn.

Nói cách khác, hãy cố gắng nghĩ về những thứ khác ngoài ví dụ không thú vị này :

• if(5 == x) thay vì if(x == 5) : để tránh sự phân công ngoài ý muốn

Dưới đây là một số ví dụ về một số thực tiễn lập trình phòng thủ tốt nhất hấp dẫn (ví dụ cụ thể về ngôn ngữ trong Java):

- Khóa các biến của bạn cho đến khi bạn biết rằng bạn cần thay đổi chúng

Đó là, bạn có thể khai báo tất cả các biến finalcho đến khi bạn biết rằng bạn sẽ cần thay đổi nó, tại thời điểm đó bạn có thể loại bỏ final. Một thực tế thường được biết là điều này cũng hợp lệ cho các tham số của phương thức:

public void foo(final int arg) { /* Stuff Here */ }

- Khi có điều gì xấu xảy ra, hãy để lại dấu vết bằng chứng

Có một số điều bạn có thể làm khi có ngoại lệ: rõ ràng đăng nhập nó và thực hiện một số dọn dẹp sẽ là một số ít. Nhưng bạn cũng có thể để lại một dấu vết bằng chứng (ví dụ: đặt các biến thành các giá trị sentinel như "UNABLE TO LOAD FILE" hoặc 99999 sẽ hữu ích trong trình gỡ lỗi, trong trường hợp bạn catchtình cờ thổi qua một ngoại lệ -block).

- Khi nói đến sự nhất quán: ma quỷ nằm trong các chi tiết

Hãy nhất quán với các thư viện khác mà bạn đang sử dụng. Ví dụ, trong Java, nếu bạn đang tạo một phương pháp mà chiết xuất một loạt các giá trị làm cho thấp hơn bị ràng buộc bao gồm và các ràng buộc trên độc quyền . Điều này sẽ làm cho nó phù hợp với các phương thức như String.substring(start, end)hoạt động theo cùng một cách. Bạn sẽ tìm thấy tất cả các loại phương thức này trong Sun JDK để hành xử theo cách này vì nó thực hiện các hoạt động khác nhau bao gồm lặp các phần tử phù hợp với mảng, trong đó các chỉ số từ Zero ( bao gồm ) đến độ dài của mảng (loại trừ ).

Vì vậy, một số thực hành phòng thủ yêu thích của bạn là gì?

Cập nhật: Nếu bạn chưa có, hãy thoải mái bấm chuông. Tôi sẽ có cơ hội nhận được nhiều phản hồi hơn trước khi tôi chọn câu trả lời chính thức .

Trong c ++, tôi đã từng thích xác định lại mới để nó cung cấp thêm một số bộ nhớ để bắt lỗi hàng rào.

Hiện tại, tôi thích tránh lập trình phòng thủ có lợi cho Test Driven Development . Nếu bạn bắt lỗi nhanh chóng và từ bên ngoài, bạn không cần phải làm rối mã của mình bằng các thao tác phòng thủ, mã của bạn là DRY -er và bạn sẽ có ít lỗi hơn để chống lại.

Như WikiKnowledge đã viết :

Tránh lập trình phòng thủ, thất bại nhanh thay.

Bằng lập trình phòng thủ, ý tôi là thói quen viết mã cố gắng bù đắp một số lỗi trong dữ liệu, viết mã giả định rằng người gọi có thể cung cấp dữ liệu không phù hợp với hợp đồng giữa người gọi và chương trình con và bằng cách nào đó chương trình con phải đối phó với nó.

SQL

Khi tôi phải xóa dữ liệu, tôi viết

select *    
--delete    
From mytable    
Where ...

Khi tôi chạy nó, tôi sẽ biết nếu tôi quên hoặc làm hỏng mệnh đề where. Tôi có một sự an toàn. Nếu mọi thứ đều ổn, tôi làm nổi bật mọi thứ sau mã thông báo '-' và chạy nó.

Chỉnh sửa: nếu tôi xóa nhiều dữ liệu, tôi sẽ sử dụng tính (*) thay vì chỉ *

Phân bổ một đoạn bộ nhớ hợp lý khi ứng dụng khởi động - Tôi nghĩ Steve McConnell gọi đây là một chiếc dù bộ nhớ trong Code Complete.

Điều này có thể được sử dụng trong trường hợp một cái gì đó nghiêm trọng đi sai và bạn được yêu cầu chấm dứt.

Phân bổ bộ nhớ này lên phía trước cung cấp cho bạn một mạng lưới an toàn, vì bạn có thể giải phóng nó và sau đó sử dụng bộ nhớ khả dụng để làm như sau:

• Lưu tất cả dữ liệu liên tục
• Đóng tất cả các tệp thích hợp
• Viết thông báo lỗi vào một tệp nhật ký
• Trình bày một lỗi có ý nghĩa cho người dùng

Trong mọi câu lệnh chuyển đổi không có trường hợp mặc định, tôi thêm trường hợp hủy bỏ chương trình với thông báo lỗi.

#define INVALID_SWITCH_VALUE 0

switch (x) {
case 1:
  // ...
  break;
case 2:
  // ...
  break;
case 3:
  // ...
  break;
default:
  assert(INVALID_SWITCH_VALUE);
}

Khi bạn xử lý các trạng thái khác nhau của enum (C #):

enum AccountType
{
    Savings,
    Checking,
    MoneyMarket
}

Sau đó, bên trong một số thói quen ...

switch (accountType)
{
    case AccountType.Checking:
        // do something

    case AccountType.Savings:
        // do something else

    case AccountType.MoneyMarket:
        // do some other thing

    default:
-->     Debug.Fail("Invalid account type.");
}

Tại một số điểm tôi sẽ thêm một loại tài khoản khác vào enum này. Và khi tôi làm, tôi sẽ quên sửa câu lệnh chuyển đổi này. Vì vậy, các Debug.Failsự cố khủng khiếp (trong chế độ Gỡ lỗi) để thu hút sự chú ý của tôi vào thực tế này. Khi tôi thêm case AccountType.MyNewAccountType:, sự cố khủng khiếp dừng lại ... cho đến khi tôi thêm một loại tài khoản khác và quên cập nhật các trường hợp ở đây.

(Vâng, tính đa hình có lẽ tốt hơn ở đây, nhưng đây chỉ là một ví dụ ngoài đỉnh đầu của tôi.)

Khi in ra các thông báo lỗi bằng một chuỗi (đặc biệt là một chuỗi phụ thuộc vào đầu vào của người dùng), tôi luôn sử dụng các dấu ngoặc đơn ''. Ví dụ:

FILE *fp = fopen(filename, "r");
if(fp == NULL) {
    fprintf(stderr, "ERROR: Could not open file %s\n", filename);
    return false;
}

Việc thiếu dấu ngoặc kép %snày thực sự rất tệ, bởi vì nói tên tệp là một chuỗi rỗng hoặc chỉ là khoảng trắng hoặc một cái gì đó. Tất nhiên, thông điệp được in ra sẽ là:

ERROR: Could not open file

Vì vậy, luôn luôn tốt hơn để làm:

fprintf(stderr, "ERROR: Could not open file '%s'\n", filename);

Sau đó, ít nhất người dùng sẽ thấy điều này:

ERROR: Could not open file ''

Tôi thấy rằng điều này tạo ra một sự khác biệt lớn về chất lượng của các báo cáo lỗi được gửi bởi người dùng cuối. Nếu có một thông báo lỗi trông buồn cười như thế này thay vì một âm thanh chung chung, thì nhiều khả năng họ sẽ sao chép / dán nó thay vì chỉ viết "nó sẽ không mở các tệp của tôi".

An toàn SQL

Trước khi viết bất kỳ SQL nào sẽ sửa đổi dữ liệu, tôi bao bọc toàn bộ trong một giao dịch được khôi phục:

BEGIN TRANSACTION
-- LOTS OF SCARY SQL HERE LIKE
-- DELETE FROM ORDER INNER JOIN SUBSCRIBER ON ORDER.SUBSCRIBER_ID = SUBSCRIBER.ID
ROLLBACK TRANSACTION

Điều này ngăn bạn thực hiện xóa / cập nhật xấu vĩnh viễn. Và, bạn có thể thực thi toàn bộ và xác minh số lượng bản ghi hợp lý hoặc thêm các SELECTcâu lệnh giữa SQL của bạn và ROLLBACK TRANSACTIONđể đảm bảo mọi thứ đều ổn.

Khi bạn hoàn toàn chắc chắn nó làm những gì bạn mong đợi, hãy thay đổi ROLLBACKthành COMMITvà chạy thật.

Đối với tất cả các ngôn ngữ:

Giảm phạm vi của các biến đến mức tối thiểu có thể yêu cầu. Các biến Eschew chỉ được cung cấp để đưa chúng vào câu lệnh tiếp theo. Các biến không tồn tại là các biến bạn không cần phải hiểu và bạn không thể chịu trách nhiệm. Sử dụng Lambdas bất cứ khi nào có thể cho cùng một lý do.

Khi nghi ngờ, đánh bom ứng dụng!

Kiểm tra từng tham số ở đầu mỗi phương thức (dù tự mã hóa nó hay sử dụng lập trình dựa trên hợp đồng không quan trọng ở đây) và ném bom với ngoại lệ chính xác và / hoặc thông báo lỗi có ý nghĩa nếu có bất kỳ điều kiện tiên quyết nào đối với mã không gặp

Tất cả chúng ta đều biết về các điều kiện tiên quyết ngầm này khi chúng ta viết mã , nhưng nếu chúng không được kiểm tra rõ ràng, chúng ta sẽ tạo ra mê cung cho chính mình khi có sự cố xảy ra sau đó và hàng chục phương thức gọi riêng biệt sự xuất hiện của triệu chứng và vị trí thực tế trong đó một điều kiện tiên quyết không được đáp ứng (= nơi thực sự có vấn đề / lỗi).

Trong Java, đặc biệt là với các bộ sưu tập, hãy sử dụng API, vì vậy nếu phương thức của bạn trả về Danh sách loại (ví dụ), hãy thử như sau:

public List<T> getList() {
    return Collections.unmodifiableList(list);
}

Đừng cho phép bất cứ điều gì thoát khỏi lớp học của bạn mà bạn không cần!

ở Perl, ai cũng vậy

use warnings;

tôi thích

use warnings FATAL => 'all';

Điều này làm cho mã chết cho bất kỳ cảnh báo trình biên dịch / thời gian chạy. Điều này chủ yếu là hữu ích trong việc bắt các chuỗi chưa được khởi tạo.

use warnings FATAL => 'all';
...
my $string = getStringVal(); # something bad happens;  returns 'undef'
print $string . "\n";        # code dies here

C #:

string myString = null;

if (myString.Equals("someValue")) // NullReferenceException...
{

}

if ("someValue".Equals(myString)) // Just false...
{

}

Trong kiểm tra c # của chuỗi.IsNullOrEmpty trước khi thực hiện bất kỳ thao tác nào trên chuỗi như length, indexOf, mid, v.v.

public void SomeMethod(string myString)
{
   if(!string.IsNullOrEmpty(myString)) // same as myString != null && myString != string.Empty
   {                                   // Also implies that myString.Length == 0
     //Do something with string
   }
}

[Chỉnh sửa]
Bây giờ tôi cũng có thể thực hiện các thao tác sau trong .NET 4.0, kiểm tra thêm nếu giá trị chỉ là khoảng trắng

string.IsNullOrWhiteSpace(myString)

Trong Java và C #, đặt cho mỗi luồng một tên có ý nghĩa. Điều này bao gồm chủ đề nhóm chủ đề. Nó làm cho các bãi chứa stack có ý nghĩa hơn nhiều. Phải mất thêm một chút nỗ lực để đặt một cái tên có ý nghĩa cho các luồng xử lý nhóm luồng, nhưng nếu một nhóm luồng có vấn đề trong một ứng dụng chạy dài, tôi có thể khiến kết xuất ngăn xếp xảy ra (bạn có biết về SendSignal.exe không? ), lấy các bản ghi và không phải làm gián đoạn một hệ thống đang chạy Tôi có thể biết chủ đề nào là ... bất cứ điều gì. Bế tắc, rò rỉ, phát triển, bất kể vấn đề là gì.

Với VB.NET, có tùy chọn Explicit và Option Strict được bật theo mặc định cho toàn bộ Visual Studio.

C ++

#define SAFE_DELETE(pPtr)   { delete pPtr; pPtr = NULL; }
#define SAFE_DELETE_ARRAY(pPtr) { delete [] pPtr; pPtr = NULL }

sau đó thay thế tất cả các cuộc gọi ' xóa pPtr ' và ' xóa [] pPtr ' của bạn bằng SAFE_DELETE (pPtr) và SAFE_DELETE_ARRAY (pPtr)

Bây giờ do nhầm lẫn nếu bạn sử dụng con trỏ 'pPtr' sau khi xóa nó, bạn sẽ gặp lỗi 'vi phạm truy cập'. Nó dễ dàng sửa chữa hơn nhiều so với hỏng bộ nhớ ngẫu nhiên.

Với Java, có thể thuận tiện để sử dụng từ khóa khẳng định, ngay cả khi bạn chạy mã sản xuất với các xác nhận đã tắt:

private Object someHelperFunction(Object param)
{
    assert param != null : "Param must be set by the client";

    return blahBlah(param);
}

Ngay cả khi xác nhận tắt, ít nhất là mã tài liệu thực tế là param dự kiến ​​sẽ được đặt ở đâu đó. Lưu ý rằng đây là chức năng trợ giúp riêng tư và không phải là thành viên của API công khai. Phương pháp này chỉ có thể được gọi bởi bạn, vì vậy bạn có thể đưa ra một số giả định nhất định về cách sử dụng nó. Đối với các phương thức công khai, có lẽ tốt hơn là ném một ngoại lệ thực sự cho đầu vào không hợp lệ.

Tôi đã không tìm thấy readonlytừ khóa cho đến khi tôi tìm thấy ReSharper, nhưng bây giờ tôi sử dụng nó theo bản năng, đặc biệt là cho các lớp dịch vụ.

readonly var prodSVC = new ProductService();

Trong Java, khi một cái gì đó đang xảy ra và tôi không biết tại sao, đôi khi tôi sẽ sử dụng Log4J như thế này:

if (some bad condition) {
    log.error("a bad thing happened", new Exception("Let's see how we got here"));
}

bằng cách này, tôi nhận được một dấu vết ngăn xếp cho tôi thấy tôi đã gặp phải tình huống bất ngờ như thế nào, nói rằng một khóa không bao giờ được mở khóa, một cái gì đó không thể là null, v.v. Rõ ràng, nếu một Ngoại lệ thực sự bị ném, tôi không cần phải làm điều này. Đây là khi tôi cần xem những gì đang xảy ra trong mã sản xuất mà không thực sự làm phiền bất cứ điều gì khác. Tôi không muốn ném Ngoại lệ và tôi đã không bắt được. Tôi chỉ muốn một dấu vết ngăn xếp được ghi lại với một thông điệp thích hợp để gắn cờ tôi với những gì đang xảy ra.

Nếu bạn đang sử dụng Visual C ++, hãy sử dụng từ khóa ghi đè bất cứ khi nào bạn phương thức của lớp cơ sở. Bằng cách này, nếu bất cứ ai từng thay đổi chữ ký lớp cơ sở, nó sẽ đưa ra một lỗi trình biên dịch thay vì phương thức sai được gọi âm thầm. Điều này sẽ cứu tôi một vài lần nếu nó tồn tại trước đó.

Thí dụ:

class Foo
{
   virtual void DoSomething();
}

class Bar: public Foo
{
   void DoSomething() override { /* do something */ }
}

Tôi đã học được ở Java gần như không bao giờ chờ đợi một khóa để mở khóa, trừ khi tôi thực sự mong đợi rằng nó có thể mất một thời gian dài vô tận. Nếu thực tế, khóa sẽ mở khóa trong vòng vài giây, sau đó tôi sẽ chỉ đợi trong một khoảng thời gian nhất định. Nếu khóa không mở khóa, thì tôi phàn nàn và đổ chồng vào nhật ký, và tùy thuộc vào điều gì là tốt nhất cho sự ổn định của hệ thống, hãy tiếp tục như thể khóa được mở khóa, hoặc tiếp tục như thể khóa không bao giờ mở khóa.

Điều này đã giúp cô lập một vài điều kiện chủng tộc và điều kiện bế tắc giả là bí ẩn trước khi tôi bắt đầu làm điều này.

C #

• Xác minh các giá trị không null cho các tham số loại tham chiếu trong phương thức công khai.
• Tôi sử dụng sealedrất nhiều cho các lớp học để tránh giới thiệu các phụ thuộc mà tôi không muốn chúng. Cho phép thừa kế nên được thực hiện rõ ràng và không phải ngẫu nhiên.

Khi bạn đưa ra thông báo lỗi, ít nhất là cố gắng cung cấp cùng thông tin mà chương trình có khi đưa ra quyết định đưa ra lỗi.

"Quyền bị từ chối" cho bạn biết có vấn đề về quyền, nhưng bạn không biết tại sao hoặc sự cố xảy ra. "Không thể viết nhật ký giao dịch / my / file: Hệ thống tệp chỉ đọc" ít nhất cho bạn biết cơ sở quyết định được đưa ra, ngay cả khi nó sai - đặc biệt là nếu nó sai: tên tệp sai? mở sai? lỗi bất ngờ khác? - và cho bạn biết bạn đã ở đâu khi gặp sự cố.

Trong C #, sử dụng astừ khóa để truyền.

string a = (string)obj

sẽ ném một ngoại lệ nếu obj không phải là một chuỗi

string a = obj as string

sẽ để lại là null nếu obj không phải là một chuỗi

Bạn vẫn cần tính đến null, nhưng điều đó thường đơn giản hơn về phía trước sau đó tìm kiếm các ngoại lệ diễn viên. Đôi khi bạn muốn hành vi loại "cast hoặc blow up", trong trường hợp đó (string)objcú pháp được ưu tiên.

Trong mã của riêng tôi, tôi thấy tôi sử dụng ascú pháp khoảng 75% thời gian và (cast)cú pháp khoảng 25%.

Hãy chuẩn bị cho bất kỳ đầu vào , và bất kỳ đầu vào nào bạn nhận được bất ngờ, đổ vào nhật ký. (Trong lý do. Nếu bạn đang đọc mật khẩu từ người dùng, đừng đổ nó vào nhật ký! Và đừng ghi nhật ký hàng ngàn loại tin nhắn này vào nhật ký mỗi giây. .)

Tôi không chỉ nói về xác nhận đầu vào của người dùng. Ví dụ: nếu bạn đang đọc các yêu cầu HTTP mà bạn muốn chứa XML, hãy chuẩn bị cho các định dạng dữ liệu khác. Tôi đã rất ngạc nhiên khi thấy các phản hồi HTML mà tôi chỉ mong đợi XML - cho đến khi tôi nhìn và thấy rằng yêu cầu của tôi đang thông qua một proxy minh bạch, tôi không biết và khách hàng đã tuyên bố không biết gì - và proxy đã hết thời gian cố gắng hoàn thành yêu cầu. Do đó, proxy đã trả lại một trang lỗi HTML cho khách hàng của tôi, gây nhầm lẫn cho khách hàng chỉ mong đợi dữ liệu XML.

Do đó, ngay cả khi bạn nghĩ rằng bạn điều khiển cả hai đầu dây, bạn có thể nhận được các định dạng dữ liệu bất ngờ mà không có bất kỳ kẻ xấu nào tham gia. Hãy chuẩn bị, mã phòng thủ và cung cấp đầu ra chẩn đoán trong trường hợp đầu vào bất ngờ.

Tôi cố gắng sử dụng Thiết kế theo cách tiếp cận Hợp đồng. Nó có thể được mô phỏng thời gian chạy bằng bất kỳ ngôn ngữ. Mọi ngôn ngữ đều hỗ trợ "khẳng định", nhưng thật dễ dàng và thuận tiện để viết một triển khai tốt hơn cho phép bạn quản lý lỗi theo cách hữu ích hơn.

Trong 25 lỗi lập trình nguy hiểm nhất , "Xác thực đầu vào không đúng" là lỗi nguy hiểm nhất trong phần "Tương tác không an toàn giữa các thành phần".

Thêm các xác nhận điều kiện tiên quyết vào đầu các phương thức là một cách tốt để đảm bảo rằng các tham số phù hợp. Khi kết thúc các phương thức tôi viết các postconditions , kiểm tra xem đầu ra đó có phải là những gì được dự định không.

Để thực hiện bất biến , tôi viết một phương thức trong bất kỳ lớp nào kiểm tra "tính nhất quán của lớp", nên được gọi là authomatically bởi macro điều kiện tiên quyết và hậu điều kiện.

Tôi đang đánh giá Thư viện hợp đồng mã .

Java

Api java không có khái niệm về các đối tượng bất biến, đó là xấu! Cuối cùng có thể giúp bạn trong trường hợp đó. Gắn thẻ cho mỗi lớp là bất biến với cuối cùng và chuẩn bị lớp phù hợp .

Đôi khi rất hữu ích khi sử dụng cuối cùng trên các biến cục bộ để đảm bảo chúng không bao giờ thay đổi giá trị của chúng. Tôi thấy điều này hữu ích trong các cấu trúc vòng lặp xấu xí, nhưng cần thiết. Nó chỉ đơn giản là dễ dàng vô tình sử dụng lại một biến mặc dù nó là một hằng số.

Sử dụng sao chép phòng thủ trong getters của bạn. Trừ khi bạn trả về một kiểu nguyên thủy hoặc một đối tượng bất biến, hãy đảm bảo bạn sao chép đối tượng để không vi phạm đóng gói.

Không bao giờ sử dụng bản sao, sử dụng một constructor sao chép .

Tìm hiểu hợp đồng giữa bằng và hashCode. Điều này bị vi phạm thường xuyên. Vấn đề là nó không ảnh hưởng đến mã của bạn trong 99% trường hợp. Mọi người ghi đè bằng, nhưng không quan tâm đến hashCode. Có những trường hợp trong mã của bạn có thể phá vỡ hoặc hành xử lạ, ví dụ: sử dụng các đối tượng có thể thay đổi làm khóa trong bản đồ.

Tôi đã quên viết echobằng PHP quá nhiều lần:

<td><?php $foo->bar->baz(); ?></td>
<!-- should have been -->
<td><?php echo $foo->bar->baz(); ?></td>

Tôi sẽ mất mãi mãi để cố gắng tìm hiểu tại sao -> baz () không trả lại bất cứ thứ gì trong khi thực tế tôi chỉ không lặp lại nó! : -S Vì vậy, tôi đã tạo một EchoMelớp có thể được bao quanh bất kỳ giá trị nào cần được lặp lại:

<?php
class EchoMe {
  private $str;
  private $printed = false;
  function __construct($value) {
    $this->str = strval($value);
  }
  function __toString() {
    $this->printed = true;
    return $this->str;
  }
  function __destruct() {
    if($this->printed !== true)
      throw new Exception("String '$this->str' was never printed");
  }
}

Và sau đó, đối với môi trường phát triển, tôi đã sử dụng EchoMe để bọc những thứ cần được in:

function baz() {
  $value = [...calculations...]
  if(DEBUG)
    return EchoMe($value);
  return $value;
}

Sử dụng kỹ thuật đó, ví dụ đầu tiên thiếu echohiện tại sẽ tạo ra một ngoại lệ ...

C ++

Khi tôi gõ mới, tôi phải gõ ngay lập tức. Đặc biệt là cho mảng.

C #

Kiểm tra null trước khi truy cập các thuộc tính, đặc biệt là khi sử dụng mẫu Người hòa giải. Các đối tượng được thông qua (và sau đó nên được sử dụng như, như đã được lưu ý), và sau đó kiểm tra chống null. Ngay cả khi bạn nghĩ rằng nó sẽ không có giá trị, dù sao đi nữa, hãy kiểm tra. Tôi đã rất ngạc nhiên.

Sử dụng một hệ thống ghi nhật ký cho phép năng động, chạy điều chỉnh mức nhật ký thời gian. Thông thường nếu bạn phải dừng chương trình để bật ghi nhật ký, bạn sẽ mất bất kỳ trạng thái hiếm gặp nào xảy ra lỗi. Bạn cần có thể bật thêm thông tin đăng nhập mà không cần dừng quá trình.

Ngoài ra, 'strace -p [pid]' trên linux sẽ hiển thị cho bạn muốn hệ thống gọi một quy trình (hoặc luồng linux) đang thực hiện. Thoạt nhìn có vẻ lạ, nhưng một khi bạn đã quen với những cuộc gọi hệ thống thường được thực hiện bởi những gì libc gọi, bạn sẽ thấy điều này là vô giá trong chẩn đoán hiện trường.