Some examples crash with SEGV

[yurivict]

For example:

$ python3.7 ./work/or-tools-7.7/ortools/sat/samples/cp_is_fun_sat.py
C=2 P=3 I=7 S=4 F=9 U=6 N=8 T=1 R=0 E=5 
C=2 P=4 I=7 S=3 F=9 U=6 N=8 T=1 R=0 E=5 
C=2 P=4 I=7 S=8 F=9 U=6 N=3 T=1 R=0 E=5 
...skipped...
C=7 P=3 I=2 S=8 F=9 U=6 N=4 T=1 R=0 E=5 
C=4 P=3 I=5 S=8 F=9 U=2 N=6 T=1 R=0 E=7 
C=4 P=3 I=5 S=6 F=9 U=2 N=8 T=1 R=0 E=7 
Segmentation fault

Stack:

(gdb) bt
#0  0x00000008023ec26f in ?? () from /usr/local/lib/python3.7/site-packages/ortools/sat/_pywrapsat.so
#1  0x0000000800368bb3 in _PyMethodDef_RawFastCallKeywords () from /usr/local/lib/libpython3.7m.so.1.0
#2  0x00000008003680a9 in _PyCFunction_FastCallKeywords () from /usr/local/lib/libpython3.7m.so.1.0
#3  0x000000080042ba23 in ?? () from /usr/local/lib/libpython3.7m.so.1.0
#4  0x0000000800428df2 in _PyEval_EvalFrameDefault () from /usr/local/lib/libpython3.7m.so.1.0
#5  0x0000000800368544 in ?? () from /usr/local/lib/libpython3.7m.so.1.0
#6  0x000000080042ba8f in ?? () from /usr/local/lib/libpython3.7m.so.1.0
#7  0x0000000800428df2 in _PyEval_EvalFrameDefault () from /usr/local/lib/libpython3.7m.so.1.0
#8  0x0000000800368544 in ?? () from /usr/local/lib/libpython3.7m.so.1.0
#9  0x000000080042ba8f in ?? () from /usr/local/lib/libpython3.7m.so.1.0
#10 0x0000000800428dd8 in _PyEval_EvalFrameDefault () from /usr/local/lib/libpython3.7m.so.1.0
#11 0x0000000800368544 in ?? () from /usr/local/lib/libpython3.7m.so.1.0
#12 0x000000080042ba8f in ?? () from /usr/local/lib/libpython3.7m.so.1.0
#13 0x0000000800428e7c in _PyEval_EvalFrameDefault () from /usr/local/lib/libpython3.7m.so.1.0
#14 0x000000080042c407 in _PyEval_EvalCodeWithName () from /usr/local/lib/libpython3.7m.so.1.0
#15 0x0000000800422f43 in PyEval_EvalCode () from /usr/local/lib/libpython3.7m.so.1.0
#16 0x000000080045e5fe in PyRun_FileExFlags () from /usr/local/lib/libpython3.7m.so.1.0
#17 0x000000080045db5b in PyRun_SimpleFileExFlags () from /usr/local/lib/libpython3.7m.so.1.0
#18 0x000000080047f2b2 in ?? () from /usr/local/lib/libpython3.7m.so.1.0
#19 0x000000080047fc55 in _Py_UnixMain () from /usr/local/lib/libpython3.7m.so.1.0
#20 0x000000000020110f in _start ()

OS: FreeBSD 12.1

[lperron]

I have fixed a race condition that is platform dependent. Can you try with the master branch ?

[lperron]

CP-SAT works fine now. CP crashes though

[Mizux]

To investigate:

$ make --directory=cmake freebsd
$ cd cmake/vagrant/freebsd
$ vagrant status
...
default                   running (virtualbox)
$ vagrant ssh
[vagrant@freebsd12 ~]$ cd project/
[vagrant@freebsd12 ~/project]$ cmake --build build --target test
...
The following tests FAILED:
CMake Error: Cannot open file for write: /usr/home/vagrant/project/build/Testing/Temporary/LastTestsFailed.log.tmp
CMake Error: : System Error: Permission denied
Problem opening file: /usr/home/vagrant/project/build/Testing/Temporary/LastTestsFailed.log
Cannot create log file: LastTestsFailed.log
	 13 - cxx_constraint_solver_minimal_jobshop_cp (SEGFAULT)
	 16 - cxx_constraint_solver_simple_cp_program (SEGFAULT)
	 17 - cxx_constraint_solver_simple_ls_program (SEGFAULT)
	 34 - cxx_constraint_solver_vrp_with_time_limit (SEGFAULT)
[vagrant@freebsd12 ~/project]$ sudo pkg install gdb
[vagrant@freebsd12 ~/project]$ cd build/bin/
[vagrant@freebsd12 ~/project/build/bin]$ gdb --args minimal_jobshop_cp
(gdb) run
Starting program: /usr/home/vagrant/project/build/bin/minimal_jobshop_cp 
I0923 14:22:38.257535 2404352 minimal_jobshop_cp.cc:31] Machines:  0 1 2
I0923 14:22:38.257685 2404352 minimal_jobshop_cp.cc:41] Jobs:
I0923 14:22:38.257697 2404352 minimal_jobshop_cp.cc:49] Job 0: [(0, 3)(1, 2)(2, 2)]
I0923 14:22:38.257704 2404352 minimal_jobshop_cp.cc:49] Job 1: [(0, 2)(2, 1)(1, 4)]
I0923 14:22:38.257709 2404352 minimal_jobshop_cp.cc:49] Job 2: [(1, 4)(2, 3)]
I0923 14:22:38.257714 2404352 minimal_jobshop_cp.cc:59] Horizon: 21

Program received signal SIGSEGV, Segmentation fault.
0x0000000801fda0c9 in fclose () from /lib/libc.so.7
(gdb) bt
#0  0x0000000801fda0c9 in fclose () from /lib/libc.so.7
#1  0x0000000800c1e62e in operations_research::GetProcessMemoryUsage() () from /usr/home/vagrant/project/build/bin/../lib/libortools.so.8
#2  0x0000000800e35121 in operations_research::SearchLog::MemoryUsage() () from /usr/home/vagrant/project/build/bin/../lib/libortools.so.8
#3  0x0000000800e3505c in operations_research::SearchLog::EnterSearch() () from /usr/home/vagrant/project/build/bin/../lib/libortools.so.8
#4  0x0000000800c5f8f9 in operations_research::Solver::NewSearch(operations_research::DecisionBuilder*, std::__1::vector<operations_research::SearchMonitor*, std::__1::allocator<operations_research::SearchMonitor*> > const&) ()
   from /usr/home/vagrant/project/build/bin/../lib/libortools.so.8
#5  0x0000000800c5f561 in operations_research::Solver::Solve(operations_research::DecisionBuilder*, operations_research::SearchMonitor*, operations_research::SearchMonitor*, operations_research::SearchMonitor*, operations_research::SearchMonitor*) () from /usr/home/vagrant/project/build/bin/../lib/libortools.so.8
#6  0x00000000002056a0 in operations_research::SolveJobShopExample() ()
#7  0x0000000000206a6b in main ()

I would say operations_research::GetProcessMemoryUsage() is not FreeBSD friendly, still investigating...

• minimal_jobshop_cp: operations_research::GetProcessMemoryUsage()
• simple_cp_program: same
• simple_ls_program: same
• vrp_with_time_limit: same

[Mizux]

or-tools/ortools/base/sysinfo.cc

Lines 47 to 76 in a0a5669

	#elif defined(__GNUC__) // LINUX
	int64 GetProcessMemoryUsage() {
	unsigned size = 0;
	char buf[30];
	snprintf(buf, sizeof(buf), "/proc/%u/statm", (unsigned)getpid());
	FILE* const pf = fopen(buf, "r");
	if (pf) {
	if (fscanf(pf, "%u", &size) != 1) return 0;
	}
	fclose(pf);
	return size * GG_LONGLONG(1024);
	}
	#elif defined(_MSC_VER) // WINDOWS
	int64 GetProcessMemoryUsage() {
	HANDLE hProcess;
	PROCESS_MEMORY_COUNTERS pmc;
	hProcess = OpenProcess(PROCESS_QUERY_INFORMATION | PROCESS_VM_READ, FALSE,
	GetCurrentProcessId());
	int64 memory = 0;
	if (hProcess) {
	if (GetProcessMemoryInfo(hProcess, &pmc, sizeof(pmc))) {
	memory = pmc.WorkingSetSize;
	}
	CloseHandle(hProcess);
	}
	return memory;
	}
	#else // Unknown, returning 0.
	int64 GetProcessMemoryUsage() { return 0; }
	#endif

[Mizux]

On FreeBSD we are now using this:
5de85ed
So it is the peak (maximum so far) resident set size (physical memory use) instead of the current RSS.