Đó là lỗi số 961964 của MATLAB được biết đến từ phiên bản R2012b (8.0). MATLAB tải động một số lib với TLS tĩnh (lưu trữ cục bộ luồng, ví dụ: xem cờ trình biên dịch gcc -ftls-model). Đang tải quá nhiều lib như vậy => không còn chỗ trống.
Cách giải quyết duy nhất cho đến nay của mathwork là tải các lib quan trọng (!) Trước bằng cách sử dụng chúng sớm (họ đề nghị đặt "ones (10) * ones (10);" trong startup.m). Tốt hơn là tôi không bình luận về "chiến lược giải pháp" này.
Kể từ R2013b (8.2.0.701) với Linux x86_64, kinh nghiệm của tôi là: Không sử dụng "doc" (hệ thống trợ giúp đồ họa)! Tôi nghĩ rằng tiện ích doc này (libxul, v.v.) đang sử dụng rất nhiều bộ nhớ TLS tĩnh.
Đây là bản cập nhật (2013/12/31)
Tất cả các thử nghiệm sau được thực hiện với Fedora 20 (với glibc-2.18-11.fc20) và Matlab 8.3.0.73043 (R2014a Prerelease).
Để biết thêm thông tin về TLS, hãy xem Ulrich Drepper, xử lý ELF Đối với Bộ nhớ Cục bộ- Luồng , Phiên bản 0.21, 2013, hiện có tại Akkadia và Redhat .
Điều gì xảy ra chính xác?
MATLAB động (với dlopen) tải một số thư viện cần khởi tạo tls. Tất cả các lib đó cần một khe trong dtv (vectơ chủ đề động). Vì MATLAB tải động một số lib này trong thời gian chạy ở thời gian biên dịch / liên kết nên trình liên kết (tại các công trình toán học) không có cơ hội để đếm các vị trí cần thiết (đó là phần quan trọng). Bây giờ, nhiệm vụ của trình tải lib động là xử lý một trường hợp như vậy trong thời gian chạy. Nhưng điều này không hề dễ dàng. Để trích dẫn dl-open.c:
Đối với TLS tĩnh, chúng ta phải cấp phát bộ nhớ ở đây và bây giờ. Điều này bao gồm cấp phát bộ nhớ trong DTV. Nhưng chúng tôi không thể thay đổi bất kỳ DTV nào khác ngoài người của chúng tôi. Vì vậy, nếu chúng tôi không thể đảm bảo rằng có chỗ trong DTV, chúng tôi thậm chí không thử nó và không tải được.
Có một hằng số thời gian biên dịch (được gọi là DTV_SURPLUS, xem glibc-source / sysdeps / generic / ldsodefs.h) trong trình tải lib động của glibc để dành một số vị trí bổ sung cho một mớ hỗn độn như vậy (tải động các lib với TLS tĩnh trong đa luồng chương trình). Trong phiên bản glibc của Fedora 20, giá trị này là 14.
Đây là libs đầu tiên (chạy MATLAB) cần khe dtv trong trường hợp của tôi:
matlabroot/bin/glnxa64/libut.so
/lib64/libstdc++.so.6
/lib64/libpthread.so.0
matlabroot/bin/glnxa64/libunwind.so.8
/lib64/libuuid.so.1
matlabroot/sys/java/jre/glnxa64/jre/lib/amd64/server/libjvm.so
matlabroot/sys/java/jre/glnxa64/jre/lib/amd64/libfontmanager.so
matlabroot/sys/java/jre/glnxa64/jre/lib/amd64/libt2k.so
matlabroot/bin/glnxa64/mkl.so
matlabroot/sys/os/glnxa64/libiomp5.so
/lib64/libasound.so.2
matlabroot/sys/jxbrowser/glnxa64/xulrunner/xulrunner-linux-64/libxul.so
/lib64/libselinux.so.1
/lib64/libpixman-1.so.0
/lib64/libEGL.so.1
/lib64/libGL.so.1
/lib64/libglapi.so.0
Có hơn 14 => quá nhiều => không còn khe trong dtv. Đó là những gì thông báo lỗi cố gắng nói với chúng tôi và đặc biệt là các công việc toán học.
Đối với hồ sơ: Để không vi phạm giấy phép của MATLAB, tôi đã không gỡ lỗi, dịch ngược hoặc tháo rời bất kỳ phần nào của tệp nhị phân được vận chuyển với MATLAB. Tôi chỉ gỡ lỗi các mã nhị phân glibc miễn phí và mở của Fedora 20 mà MATLAB đang sử dụng để tải động các lib.
Có thể làm gì, để giải quyết vấn đề này?
Có 3 lựa chọn:
(a) Xây dựng lại MATLAB và không tải động các lib đó (với mô hình tls ban đầu) thay vào đó liên kết chống lại chúng (sau đó trình liên kết có thể đếm các vị trí cần thiết!)
(b) Xây dựng lại các lib đó và đảm bảo chúng KHÔNG sử dụng mô hình tls ban đầu.
(c) Tạo lại glibc và tăng DTV_SURPLUS trong glibc / sysdeps / generic / ldsodefs.h
Rõ ràng là các phương án (a) và (b) chỉ có thể được thực hiện bởi các công việc toán học.
Đối với tùy chọn (c) không cần nguồn MATLAB và do đó có thể được thực hiện mà không cần các công việc toán học.
Tình trạng tại các công việc toán học là gì?
Tôi thực sự đã cố gắng giải thích điều này với "Bộ phận hỗ trợ kỹ thuật MathWorks". Nhưng ấn tượng của tôi là: họ không hiểu tôi. Họ đã đóng phiếu hỗ trợ của tôi và đề xuất một cuộc trò chuyện qua điện thoại (!) Vào tháng 1 năm 2014 với người quản lý hỗ trợ kỹ thuật.
Tôi sẽ cố gắng hết sức để giải thích điều này, nhưng thành thật mà nói: Tôi không tự tin lắm.
Cập nhật (2014/01/10): Hiện tại mathworks đang thử tùy chọn (b).
Cập nhật (2014/03/19): Đối với tệp libiomp5. nên bạn có thể tải xuống phiên bản mới được biên dịch (không có TLS tĩnh) tại mathworks, báo cáo lỗi 961964 . Và những người khác? Không có cải thiện ở đó. Vì vậy, đừng ngạc nhiên khi nhận được "dlopen: không thể tải thêm bất kỳ đối tượng nào có TLS tĩnh" với "doc", ví dụ: xem báo cáo lỗi 1003952 .