이것은 MVE와 관련이 있습니까? 가능한 경우 콘솔 출력과 역추적을 게시하십시오.

프로그램 수신 신호 SIGABRT, 중단됨.
[쓰레드 0x7ff426a46700(LWP 15483)으로 전환]
__GI_raise의 0x00007ff42a1c7267(sig=sig@entry=6)
../sysdeps/unix/sysv/linux/raise.c:55에서
55 ../sysdeps/unix/sysv/linux/raise.c: 해당 파일이나 디렉토리가 없습니다.
(gdb) bt

0 0x00007ff42a1c7267 in __GI_raise(sig=sig@entry=6)

at ../sysdeps/unix/sysv/linux/raise.c:55

1 0x00007ff42a1c8eca in __GI_abort() at abort.c:89

2 0x00007ff42af1006d의 __gnu_cxx::__verbose_terminate_handler() ()

/usr/lib/x86_64-linux-gnu/libstdc++.so.6에서

3 0x00007ff42af0dee6 ?? () /usr/lib/x86_64-linux-gnu/libstdc++.so.6에서

4 0x00007ff42af0cee9 ?? () /usr/lib/x86_64-linux-gnu/libstdc++.so.6에서

5 0x00007ff42af0d6ea __gxx_personality_v0()

/usr/lib/x86_64-linux-gnu/libstdc++.so.6에서

6 0x00007ff42a789ed3 ?? () /lib/x86_64-linux-gnu/libgcc_s.so.1

7 0x00007ff42a78a3f7 _Unwind_Resume()

/lib/x86_64-linux-gnu/libgcc_s.so.1에서

8 0x00000000004d58f1 _M_dispose(__a=..., this=)

at /usr/include/c++/4.9/bits/basic_string.h:240

9 ~basic_string(이=0x7ff426a457b0, __in_chrg=)

at /usr/include/c++/4.9/bits/basic_string.h:547

10 mve::View::load_image_intern (이=,

proxy=proxy@entry=0x1cd4af0, init_only=init_only@entry=false)
at view.cc:790

11 0x00000000004d5baa in mve::View::load_image ( this=this@entry=0x1cd4780 ,

proxy=proxy@entry=0x1cd4af0, update=update@entry=false) at view.cc:739

12 0x00000000004d5c30 in mve::View::get_image (this=0x1cd4780,

this@entry=0x3fc, name="original", type=type@entry=mve::IMAGE_TYPE_UINT8)

---유형계속하려면 또는 q종료합니다---
at view.cc:405

13 get_byte_image의 0x0000000000435de7(이름="원본", this=0x3fc)

at ../../libs/mve/view.h:436

14 sfm::bundler::Features::compute () at bundler_features.cc:56

15 0x00007ff42a99dc16 ?? () /usr/lib/x86_64-linux-gnu/libgomp.so.1에서

16 start_thread의 0x00007ff42a5636aa(인수=0x7ff426a46700)

at pthread_create.c:333

17 클론()의 0x00007ff42a298eed

at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

최신 버전의 MVE로 작업하고 있습니까? 문제를 지속적으로 재현할 수 있습니까? 이것은 특히 큰 데이터 세트입니까? Too many files open 오류 메시지는 어디서 받았습니까? 콘솔 출력에서 ​​볼 수 없습니다.

나는 두 대의 다른 컴퓨터와 항상 최신 버전의 MVE에서 그것을 여러 번 재현했습니다. 이 오류는 특징 감지 중에 항상 파일 1021에서 발생합니다. 데이터 세트는 거대하고 약 16000개의 사진입니다.

보기 ID 1013(1920x1080), 1860 기능은 3268ms가 걸렸습니다.
기능 감지, 보기 1021 of 16295(6.2%)...'util::Exception' 인스턴스를 throw한 후 종료가 호출되었습니다.
what(): 파일 열기 오류: 열려 있는 파일이 너무 많습니다.
중단됨(코어 덤프됨)

여러 셸은 프로세스가 열 수 있는 파일 설명자의 수를 제한합니다. bash 내에서 ulimit -n 를 사용하여 이 제한을 확인하고 설정할 수 있습니다. 기본값은 1024이며 귀하의 경우(stdin, stdout, stderr, prebundle 및 1020 기타 보기) 최대값이라고 가정합니다.
그러나 문제는 왜 그렇게 많은 보기가 동시에 열려 있느냐는 것입니다.

bash ulimit 매뉴얼 페이지

여전히 너무 많은 파일이 열려 있습니다. ulimit 물론 "해결"합니다.

다시 한 번 살펴보겠습니다.

안녕하세요 Jus80687님,
패치가 적용된 버그를 재현하려고 시도했지만 실패했습니다. 최신 버전의 코드를 컴파일했습니까?
또한 패치를 적용한 파일 수 이후에 오류가 발생합니까? 발생했을 때 역추적을 게시할 수 있습니까?
데이터 세트의 view_xxxx.mve 디렉토리 중 하나의 내용을 보내 주시겠습니까?
미리 감사드립니다.

안녕 안드레,
예, 최신 버전의 MVE를 컴파일했습니다. 패치 후 오류는 더 이상 정확히 같은 보기에서 발생하지 않지만 여전히 1024 주변에서 발생합니다. 물론 ulimit를 사용한 해결 방법은 여전히 ​​작동합니다.
사진의 수를 몇 번 바꿔서 특정 뷰와 관련이 있는 것 같지는 않습니다. 사진 자체는 영화에서 추출되며 EXIF ​​정보가 없습니다.
콘솔 출력은 변경되지 않았지만 역추적을 다시 확인해야 합니다.
당신의 도움을 주셔서 감사합니다

이 시점에서 문제를 재현하려면 추가 데이터가 필요합니다. 귀하의 견해 중 하나를 ZIP으로 보내주시겠습니까? 감사 해요.

추가 정보가 더 있습니까? 그렇지 않으면 문제가 종료됩니다.