Làm thế nào để theo dõi "tcmalloc: alloc lớn ...."

Question

in ứng dụng của tôi vài dòng như:

tcmalloc: large alloc 4294488064 bytes == 0x2b968d8000 @ 0x727432 0x727302 0x727a58 0x75a07d 0x574beb 0x585756 0x5575df 0x5717db 0x57108f 0x58078c 0x302b80610a 
tcmalloc: large alloc 4294488064 bytes == 0x2c97063000 @ 0x727432 0x727302 0x727a58 0x75a07d 0x574beb 0x585756 0x5575df 0x5717db 0x57108f 0x58078c 0x302b80610a 
tcmalloc: large alloc 4294488064 bytes == 0x2b968d8000 @ 0x727432 0x727302 0x727a58 0x75a07d 0x574beb 0x585756 0x5575df 0x5717db 0x57108f 0x58078c 0x302b80610a 

nơi nào thông điệp này đến từ đâu? nó có nghĩa là ứng dụng của tôi có một số lỗi hoặc rò rỉ bộ nhớ? làm thế nào tôi có thể theo dõi nguyên nhân gốc rễ?

Answer 1

Xem http://code.google.com/p/gperftools/source/browse/trunk/src/tcmalloc.cc?r=80&redir=1 dòng 843

Tùy thuộc vào ứng dụng của bạn - việc phân bổ lớn có thể hoặc không thể là một lỗi.

Trong mọi trường hợp - phần sau dấu @ là một stack trace và có thể được sử dụng để xác định vị trí nguồn của thông điệp

Số lặp lại (4294488064 mà có vẻ là tương đương với 4G-479.232 hoặc 0x100000000- 0x75000) làm cho tôi nghi ngờ cuộc gọi phân bổ ban đầu có giá trị đã ký âm và sử dụng giá trị chưa được ký.

Answer 2

Nếu bạn vẫn còn có quá trình chạy hoặc đã có thể lõi đổ nó (kill -ABRT) sau đó bạn sẽ có thể đính kèm gdb và chạy lệnh info symbol <address> (<address> là một trong những con số thập lục phân sau @ trong thông báo lỗi: 0x727432 ...).

Trong trường hợp của tôi, đó là lỗi xác thực.