Tại sao gỡ lỗi ngược hiếm khi được sử dụng? [đóng cửa]

gdb đã triển khai hỗ trợ để gỡ lỗi ngược trong năm 2009 (với gdb 7.0). Tôi chưa bao giờ nghe về nó cho đến năm 2012. Bây giờ tôi thấy nó cực kỳ hữu ích cho một số loại vấn đề gỡ lỗi. Tôi ước rằng tôi đã nghe nói về nó trước đây.

Chỉnh sửa nếu tôi sai nhưng ấn tượng của tôi là kỹ thuật này vẫn hiếm khi được sử dụng và hầu hết mọi người không biết rằng nó tồn tại. Tại sao?

Bạn có biết bất kỳ cộng đồng lập trình nào mà việc sử dụng gỡ lỗi ngược là phổ biến không?

Thông tin lai lịch:

• Stackoverflow: Làm thế nào để gỡ lỗi ngược hoạt động?
• gdb sử dụng thuật ngữ "gỡ lỗi ngược" nhưng các nhà cung cấp khác sử dụng các thuật ngữ khác cho các kỹ thuật giống hệt hoặc tương tự:
  • Microsoft gọi nó là IntelliTrace hoặc "Gỡ lỗi lịch sử"
  • Có một trình gỡ lỗi ngược Java có tên là Omniscient Debugger , mặc dù có lẽ nó không còn hoạt động trong Java 6
  • Có các trình gỡ lỗi ngược Java khác
  • Trình gỡ lỗi của OCaml (ocamldebug) gọi đó là du hành thời gian

Đối với một người, chạy trong chế độ gỡ lỗi với ghi âm là rất tốn kém so với chế độ gỡ lỗi thông thường; nó cũng tiêu tốn nhiều bộ nhớ hơn

Sẽ dễ dàng hơn để giảm độ chi tiết từ cấp độ đường truyền đến cấp độ cuộc gọi chức năng. Ví dụ, trình gỡ lỗi tiêu chuẩn trong nhật thực cho phép bạn "thả xuống khung", về cơ bản là một bước nhảy trở lại bắt đầu của hàm với việc thiết lập lại tất cả các tham số (không có gì được thực hiện trên heap được hoàn nguyên và finallycác khối không được thực thi , vì vậy nó không phải là một trình gỡ lỗi ngược thực sự; hãy cẩn thận về điều đó).

Lưu ý rằng điều này đã có sẵn trong vài năm nay và hoạt động cùng với việc thay thế mã nóng.

Như đã đề cập, hiệu suất là chính, ví dụ như với gỡ lỗi có thể đảo ngược của gdb, chạy một cái gì đó như gzip thấy tốc độ chậm hơn 50.000 lần so với chạy nguyên bản. Tuy nhiên, có một số lựa chọn thương mại: Tôi làm việc cho Undo undo.io và sản phẩm UndoDB của chúng tôi cũng làm như vậy nhưng với độ chậm dưới 2 lần. Có những trình gỡ lỗi thương mại đảo ngược khác có sẵn quá.

Để biết tổng quan về các lựa chọn và sản phẩm công nghệ, hãy xem một loạt các bài đăng trên blog tôi đã viết khoảng một năm trước (và một số bài tiếp theo kể từ đó):

• http://jakob.engbloms.se/archives/1547 - công nghệ
• http://jakob.engbloms.se/archives/1554 - nghiên cứu
• http://jakob.engbloms.se/archives/1564 - sản phẩm
• http://jakob.engbloms.se/archives/1768 - cập nhật bài viết trước

Cảm giác của tôi về lý do tại sao nó được sử dụng rất ít là nó đòi hỏi phần cứng đặc biệt hoặc sử dụng trình gỡ lỗi đặc biệt hoặc thiết lập hệ thống của bạn ngay. Thật không may, hầu hết mọi người không đầu tư thời gian để có được giá trị tối đa từ các công cụ gỡ lỗi của họ, thật không may.

Và thực tế là "mặc định giá rẻ" của gdb hầu như chậm một cách khó tin và có khá nhiều vấn đề ổn định cho mọi thứ trừ các hệ thống mục tiêu phổ biến nhất.

Từ kinh nghiệm của tôi với tư cách là kỹ sư bán hàng cho trình gỡ lỗi TotalView, mọi người biết rằng nó tồn tại nhưng họ không nghĩ rằng nó hoạt động, bất kể sự chậm lại (chấp nhận hay không).

Đại học Cambridge gần đây đã thực hiện một cuộc khảo sát có tên "Thất bại trong việc áp dụng chi phí gỡ lỗi ngược Kinh tế toàn cầu $ 41 tỷ hàng năm" .

Và khi trở lại GDB, tôi đã nghe (rất nhiều) rằng sự chậm chạp khiến nó khá không sử dụng được trên ứng dụng "đời thực".

Cá nhân tôi rất thích nghe lại từ nhiều người hơn bằng cách sử dụng gỡ lỗi ngược trên các ứng dụng khác ngoài "Xin chào thế giới!"

Tôi nghĩ điều quan trọng là phải mở rộng thêm một chút về việc gỡ lỗi "ngược" hoặc "lịch sử" này. Tôi nghĩ rằng để hiểu các hệ thống và hành vi phức tạp trong đó, để phát lại các "sự kiện" làm cho trạng thái rõ ràng là rất quan trọng.

Điều tôi muốn bày tỏ là bạn không đơn độc khi tự hỏi tại sao kỹ thuật này không được áp dụng nhiều hiện nay hoặc tại sao các vấn đề liên quan hiếm khi được thảo luận rõ ràng.

Vì vậy, hãy nhấn mạnh hai khái niệm rất quan trọng ở đây:

1. Để hiểu một hệ thống lập trình, thật hữu ích khi làm cho trạng thái rõ ràng

2. Để hiểu thêm về một hệ thống lập trình phát lại các chuỗi trạng thái (sự kiện) có thể giúp ích rất nhiều.

Dưới đây là một số nguồn giải quyết vấn đề và đề xuất hoặc giải pháp thiết kế cho vấn đề (xử lý trạng thái trong các hệ thống phức tạp):

-Nhưng bit tar, giấy: http://shaffner.us/cs/ con / vecit.pdf Ý tưởng chính: tránh, cô lập hoặc làm cho nhà nước rõ ràng

-CQRS http://www.cqrs.nu/ Đây là sự kết hợp của hai khái niệm: Phân đoạn truy vấn lệnh và tìm nguồn cung ứng sự kiện. Có tồn tại các triển khai khác nhau (Java, C #, Scala). Việc phát lại các chuỗi Tate và sự phát triển của một mô hình miền là những phần quan trọng ở đây.

Nếu bạn thực sự thu nhỏ và nhìn thấy bức tranh rất rộng, bạn có thể thấy rằng với sự "trỗi dậy" của lập trình chức năng, mọi người đã ((un) có ý thức) bị thu hút bởi fp vì nó làm cho trạng thái rõ ràng! Nhưng điều đó chỉ liên quan đến điểm thứ nhất, để giải quyết vấn đề thứ hai, bạn cần một khái niệm khác có thể được mô tả là "lỏng lẻo" như là lập trình phản ứng chức năng.

Vì vậy, bạn có thể nói tất cả tốt và tốt nhưng ai thực sự sử dụng CQRS và FRP? Tôi sẽ nói (IMO vì tôi không có con số cụ thể) thực sự rất nhiều công ty chỉ là họ không biết công việc họ làm có thuật ngữ này. Có thể bạn google một chút và bạn nghe từ các doanh nghiệp sử dụng CQRS, có một số câu chuyện thành công đã được đưa ra. FRP cũng đang tăng chậm như một ví dụ tôi có thể cung cấp cho Netflix: http://techblog.netflix.com/2013/02/rxjava-netflix-api.html Mà vừa phát hành một triển khai của RX thực sự dựa trên .NET (nhưng đã triển khai Javascript quá). Vì vậy, ngày nay mọi người đang sử dụng các kỹ thuật này, TRONG LỚN để hiểu các hệ thống phức tạp và làm cho chúng thậm chí còn tốt hơn. Đó là lý do tại sao họ sử dụng các kỹ thuật sửa lỗi ngược.