| ID |
Date |
Author |
Topic |
Subject |
|
1734
|
15 Nov 2019 |
Pierre Gorel | Bug Report | Newly installed MIDAS on OSX: mhttpd crahes | It is reproducible alright.
Here are the core dump and the backtrace (I think the former is more informative).
> > Context: out of the box MIDAS (using cmake) on OSX Mojave.
> >
> > Running with mongoose/opensslm installation following instruction here:
> > https://midas.triumf.ca/MidasWiki/index.php/Quickstart_Linux
> >
> > mhttpd crashing when midas webpage opened with Safari (12.1.2). Usually when opening the "chat" tab but sometimes also with the "message" tab.
> > mhttpd(11109,0x70000827a000) malloc: *** error for object 0x7f8669501ef0: pointer being freed was not allocated
> > mhttpd(11109,0x70000827a000) malloc: *** set a breakpoint in malloc_error_break to debug
> >
> > No crash if using firefox (70.0.1 (64-bit))
>
> I think we also have reports of mhttpd crash on macos with safari from the Dragon experiment,
> but cannot reproduce the problem.
>
> If you can reproduce this, can you capture the crash stack trace?
>
> One way to do this is to enable core dumps in odb "/expt/enable core dumps" set to "y", restart mhttpd,
> wait for the crash. I think macos writes core dumps into /cores/... Or you can run mhttpd inside lldb
> and wait for the crash. the lldb command to show the stack trace is "bt", but you may need
> to switch to different threads to see which one actually crashed. I forget what the command
> for that is.
>
> BTW, the mhttpd networking code has not changed in a long time, but an update
> of mongoose web server library is overdue (to fix a memory leak, at least).
>
> K.O. |
| Attachment 1: mhttpd_lldb_bt.txt
|
SnoGlobe:~/packages/midas/build> lldb mhttpd
(lldb) target create "mhttpd"
Current executable set to 'mhttpd' (x86_64).
(lldb) r
Process 15988 launched: '/Users/acquis/packages/midas/bin/mhttpd' (x86_64)
Mongoose web server will use SSL certificate file "/Users/acquis/online/ssl_cert.pem"
Mongoose web server will use authentication realm "snoglobe", password file "/Users/acquis/online/htpasswd.txt"
mongoose web server is redirecting HTTP port 8080 to https://SnoGlobe.local:8443
mongoose web server is listening on the HTTP port 8080
mongoose web server is listening on the HTTPS port 8443
mhttpd(15988,0x70000146e000) malloc: *** error for object 0x100608790: pointer being freed was not allocated
mhttpd(15988,0x70000146e000) malloc: *** set a breakpoint in malloc_error_break to debug
Process 15988 stopped
* thread #2, stop reason = signal SIGABRT
frame #0: 0x00007fff7456c2c6 libsystem_kernel.dylib`__pthread_kill + 10
libsystem_kernel.dylib`__pthread_kill:
-> 0x7fff7456c2c6 <+10>: jae 0x7fff7456c2d0 ; <+20>
0x7fff7456c2c8 <+12>: movq %rax, %rdi
0x7fff7456c2cb <+15>: jmp 0x7fff74566457 ; cerror_nocancel
0x7fff7456c2d0 <+20>: retq
Target 0: (mhttpd) stopped.
(lldb) bt
* thread #2, stop reason = signal SIGABRT
* frame #0: 0x00007fff7456c2c6 libsystem_kernel.dylib`__pthread_kill + 10
frame #1: 0x00007fff74627bf1 libsystem_pthread.dylib`pthread_kill + 284
frame #2: 0x00007fff744d66a6 libsystem_c.dylib`abort + 127
frame #3: 0x00007fff745e5077 libsystem_malloc.dylib`malloc_vreport + 545
frame #4: 0x00007fff745e4e38 libsystem_malloc.dylib`malloc_report + 151
frame #5: 0x000000010004fe53 mhttpd`AuthEntry::~AuthEntry(this=0x0000000101300220) at mhttpd.cxx:16983:8
frame #6: 0x000000010004fe25 mhttpd`AuthEntry::~AuthEntry(this=0x0000000101300220) at mhttpd.cxx:16983:8
frame #7: 0x000000010004fe09 mhttpd`std::__1::allocator<AuthEntry>::destroy(this=0x00000001001b0f10, __p=0x0000000101300220) at memory:1880:64
frame #8: 0x000000010004fddd mhttpd`void std::__1::allocator_traits<std::__1::allocator<AuthEntry> >::__destroy<AuthEntry>((null)=std::__1::true_type @ 0x000070000146cc28, __a=0x00000001001b0f10, __p=0x0000000101300220) at memory:1742:18
frame #9: 0x000000010004fd9d mhttpd`void std::__1::allocator_traits<std::__1::allocator<AuthEntry> >::destroy<AuthEntry>(__a=0x00000001001b0f10, __p=0x0000000101300220) at memory:1595:14
frame #10: 0x000000010004fd58 mhttpd`std::__1::__vector_base<AuthEntry, std::__1::allocator<AuthEntry> >::__destruct_at_end(this=0x00000001001b0f00, __new_last=0x0000000101300220) at vector:421:9
frame #11: 0x000000010004fc68 mhttpd`std::__1::__vector_base<AuthEntry, std::__1::allocator<AuthEntry> >::clear(this=0x00000001001b0f00) at vector:364:29
frame #12: 0x000000010004ff76 mhttpd`std::__1::vector<AuthEntry, std::__1::allocator<AuthEntry> >::clear(this=0x00000001001b0f00 size=1) at vector:766:17
frame #13: 0x00000001000494d3 mhttpd`read_passwords(auth=0x00000001001b0ec8) at mhttpd.cxx:17047:20
frame #14: 0x00000001000519d5 mhttpd`handle_http_message(nc=0x0000000100608860, msg=0x000070000146d5a0) at mhttpd.cxx:17719:20
frame #15: 0x00000001000499e0 mhttpd`handle_http_event_mg(nc=0x0000000100608860, ev=100, ev_data=0x000070000146d5a0) at mhttpd.cxx:17765:7
frame #16: 0x00000001000650db mhttpd`mg_call(nc=0x0000000100608860, ev_handler=(mhttpd`handle_http_event_mg(mg_connection*, int, void*) at mhttpd.cxx:17760), ev=100, ev_data=0x000070000146d5a0)(mg_connection*, int, void*), int, void*) at mongoose6.cxx:2120:5
frame #17: 0x000000010006c92b mhttpd`mg_http_call_endpoint_handler(nc=0x0000000100608860, ev=100, hm=0x000070000146d5a0) at mongoose6.cxx:4945:3
frame #18: 0x000000010006c7c5 mhttpd`mg_http_handler(nc=0x0000000100608860, ev=3, ev_data=0x000070000146dbcc) at mongoose6.cxx:5139:5
frame #19: 0x00000001000650db mhttpd`mg_call(nc=0x0000000100608860, ev_handler=(mhttpd`mg_http_handler(mg_connection*, int, void*) at mongoose6.cxx:4974), ev=3, ev_data=0x000070000146dbcc)(mg_connection*, int, void*), int, void*) at mongoose6.cxx:2120:5
frame #20: 0x00000001000670c8 mhttpd`mg_recv_common(nc=0x0000000100608860, buf=0x0000000100801000, len=401) at mongoose6.cxx:2676:3
frame #21: 0x0000000100066f83 mhttpd`mg_if_recv_tcp_cb(nc=0x0000000100608860, buf=0x0000000100801000, len=401) at mongoose6.cxx:2680:3
frame #22: 0x0000000100069d32 mhttpd`mg_read_from_socket(conn=0x0000000100608860) at mongoose6.cxx:3378:7
frame #23: 0x00000001000695f6 mhttpd`mg_mgr_handle_conn(nc=0x0000000100608860, fd_flags=1, now=1573832400.4958119) at mongoose6.cxx:3511:9
frame #24: 0x0000000100065b74 mhttpd`::mg_mgr_poll(mgr=0x000070000146ded8, timeout_ms=1000) at mongoose6.cxx:3687:5
frame #25: 0x0000000100076087 mhttpd`per_connection_thread_function(param=0x0000000100608860) at mongoose6.cxx:3805:5
frame #26: 0x00007fff746252eb libsystem_pthread.dylib`_pthread_body + 126
frame #27: 0x00007fff74628249 libsystem_pthread.dylib`_pthread_start + 66
frame #28: 0x00007fff7462440d libsystem_pthread.dylib`thread_start + 13
(lldb) .q
|
| Attachment 2: mhttpd_2019-11-15-104252_SnoGlobe.crash
|
Process: mhttpd [16037]
Path: /Users/USER/*/mhttpd
Identifier: mhttpd
Version: 0
Code Type: X86-64 (Native)
Parent Process: tcsh [16008]
Responsible: mhttpd [16037]
User ID: 501
Date/Time: 2019-11-15 10:42:51.751 -0500
OS Version: Mac OS X 10.14.6 (18G95)
Report Version: 12
Anonymous UUID: 27D16641-6679-1AAE-440D-3CF11831B5B1
Sleep/Wake UUID: 6841695D-3153-4F9B-A340-F98C52E55F40
Time Awake Since Boot: 760000 seconds
Time Since Wake: 69000 seconds
System Integrity Protection: enabled
Crashed Thread: 4
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY
Application Specific Information:
abort() called
mhttpd(16037,0x70000256e000) malloc: *** error for object 0x7fe8ba000030: pointer being freed was not allocated
Thread 0:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x00007fff7456d61a __select + 10
1 mhttpd 0x00000001003719ae mg_mgr_poll + 846 (mongoose6.cxx:3651)
2 mhttpd 0x0000000100355ca5 loop_mg() + 133 (mhttpd.cxx:18013)
3 mhttpd 0x00000001003567c9 main + 2825 (mhttpd.cxx:18271)
4 libdyld.dylib 0x00007fff744313d5 start + 1
Thread 1:
0 libsystem_kernel.dylib 0x00007fff74569f32 __semwait_signal + 10
1 libsystem_c.dylib 0x00007fff744f5914 nanosleep + 199
2 mhttpd 0x00000001003efa3e ss_sleep(int) + 126 (system.cxx:3310)
3 mhttpd 0x00000001003b43da cm_watchdog_thread(void*) + 90 (midas.cxx:6453)
4 libsystem_pthread.dylib 0x00007fff746252eb _pthread_body + 126
5 libsystem_pthread.dylib 0x00007fff74628249 _pthread_start + 66
6 libsystem_pthread.dylib 0x00007fff7462440d thread_start + 13
Thread 2:
0 libsystem_kernel.dylib 0x00007fff7456d61a __select + 10
1 mhttpd 0x00000001003719ae mg_mgr_poll + 846 (mongoose6.cxx:3651)
2 mhttpd 0x0000000100382087 per_connection_thread_function(void*) + 71 (mongoose6.cxx:3804)
3 libsystem_pthread.dylib 0x00007fff746252eb _pthread_body + 126
4 libsystem_pthread.dylib 0x00007fff74628249 _pthread_start + 66
5 libsystem_pthread.dylib 0x00007fff7462440d thread_start + 13
Thread 3:
0 mhttpd 0x0000000100405477 std::__1::enable_if<(is_move_constructible<MJsonNode**>::value) && (is_move_assignable<MJsonNode**>::value), void>::type std::__1::swap<MJsonNode**>(MJsonNode**&, MJsonNode**&) + 55 (type_traits:4506)
1 mhttpd 0x0000000100404fbd std::__1::vector<MJsonNode*, std::__1::allocator<MJsonNode*> >::__swap_out_circular_buffer(std::__1::__split_buffer<MJsonNode*, std::__1::allocator<MJsonNode*>&>&) + 125 (vector:934)
2 mhttpd 0x0000000100404d8c void std::__1::vector<MJsonNode*, std::__1::allocator<MJsonNode*> >::__push_back_slow_path<MJsonNode* const&>(MJsonNode* const&&&) + 172 (vector:1615)
3 mhttpd 0x00000001003ff204 std::__1::vector<MJsonNode*, std::__1::allocator<MJsonNode*> >::push_back(MJsonNode* const&) + 164 (vector:1633)
4 mhttpd 0x00000001003ff781 MJsonNode::AddToObject(char const*, MJsonNode*) + 113 (mjson.cxx:899)
5 mhttpd 0x0000000100410112 js_db_get_values(MJsonNode const*) + 4258 (mjsonrpc.cxx:767)
6 mhttpd 0x000000010042208b mjsonrpc_handle_request(MJsonNode const*) + 2475 (mjsonrpc.cxx:4150)
7 mhttpd 0x00000001004213dd mjsonrpc_decode_post_data(char const*) + 1293 (mjsonrpc.cxx:4265)
8 mhttpd 0x000000010035fa4a handle_http_post(mg_connection*, http_message const*, char const*, RequestTrace*) + 858 (mhttpd.cxx:17545)
9 mhttpd 0x000000010035dd41 handle_http_message(mg_connection*, http_message*) + 1745 (mhttpd.cxx:17744)
10 mhttpd 0x00000001003559e0 handle_http_event_mg(mg_connection*, int, void*) + 96 (mhttpd.cxx:17766)
11 mhttpd 0x00000001003710db mg_call(mg_connection*, void (*)(mg_connection*, int, void*), int, void*) + 427 (mongoose6.cxx:2121)
12 mhttpd 0x000000010037892b mg_http_call_endpoint_handler(mg_connection*, int, http_message*) + 203 (mongoose6.cxx:4947)
13 mhttpd 0x00000001003787c5 mg_http_handler(mg_connection*, int, void*) + 1365 (mongoose6.cxx:5141)
14 mhttpd 0x00000001003710db mg_call(mg_connection*, void (*)(mg_connection*, int, void*), int, void*) + 427 (mongoose6.cxx:2121)
15 mhttpd 0x00000001003730c8 mg_recv_common(mg_connection*, void*, int) + 312 (mongoose6.cxx:2677)
16 mhttpd 0x0000000100372f83 mg_if_recv_tcp_cb(mg_connection*, void*, int) + 35 (mongoose6.cxx:2681)
17 mhttpd 0x0000000100375d32 mg_read_from_socket(mg_connection*) + 514 (mongoose6.cxx:3379)
18 mhttpd 0x00000001003755f6 mg_mgr_handle_conn(mg_connection*, int, double) + 486
19 mhttpd 0x0000000100371b74 mg_mgr_poll + 1300 (mongoose6.cxx:3663)
20 mhttpd 0x0000000100382087 per_connection_thread_function(void*) + 71 (mongoose6.cxx:3804)
21 libsystem_pthread.dylib 0x00007fff746252eb _pthread_body + 126
22 libsystem_pthread.dylib 0x00007fff74628249 _pthread_start + 66
23 libsystem_pthread.dylib 0x00007fff7462440d thread_start + 13
Thread 4 Crashed:
0 libsystem_kernel.dylib 0x00007fff7456c2c6 __pthread_kill + 10
1 libsystem_pthread.dylib 0x00007fff74627bf1 pthread_kill + 284
2 libsystem_c.dylib 0x00007fff744d66a6 abort + 127
3 libsystem_malloc.dylib 0x00007fff745e5077 malloc_vreport + 545
4 libsystem_malloc.dylib 0x00007fff745e4e38 malloc_report + 151
5 mhttpd 0x000000010035be53 HsSchemaEntry::~HsSchemaEntry() + 35 (mhttpd.cxx:16983)
6 mhttpd 0x000000010035be25 HsSchemaEntry::~HsSchemaEntry() + 21 (mhttpd.cxx:16983)
7 mhttpd 0x000000010035be09 std::__1::allocator<AuthEntry>::destroy(AuthEntry*) + 25 (memory:1880)
8 mhttpd 0x000000010035bddd void std::__1::allocator_traits<std::__1::allocator<AuthEntry> >::__destroy<AuthEntry>(std::__1::integral_constant<bool, true>, std::__1::allocator<AuthEntry>&, AuthEntry*) + 29 (memory:1742)
9 mhttpd 0x000000010035bd9d void std::__1::allocator_traits<std::__1::allocator<AuthEntry> >::destroy<AuthEntry>(std::__1::allocator<AuthEntry>&, AuthEntry*) + 29 (memory:1595)
10 mhttpd 0x000000010035bd58 std::__1::__vector_base<AuthEntry, std::__1::allocator<AuthEntry> >::__destruct_at_end(AuthEntry*) + 88 (vector:421)
11 mhttpd 0x000000010035bc68 std::__1::__vector_base<AuthEntry, std::__1::allocator<AuthEntry> >::clear() + 24 (vector:364)
12 mhttpd 0x000000010035bf76 std::__1::vector<AuthEntry, std::__1::allocator<AuthEntry> >::clear() + 38 (vector:767)
13 mhttpd 0x00000001003554d3 read_passwords(Auth*) + 195 (mhttpd.cxx:17049)
14 mhttpd 0x000000010035d9d5 handle_http_message(mg_connection*, http_message*) + 869 (mhttpd.cxx:17719)
15 mhttpd 0x00000001003559e0 handle_http_event_mg(mg_connection*, int, void*) + 96 (mhttpd.cxx:17766)
16 mhttpd 0x00000001003710db mg_call(mg_connection*, void (*)(mg_connection*, int, void*), int, void*) + 427 (mongoose6.cxx:2121)
17 mhttpd 0x000000010037892b mg_http_call_endpoint_handler(mg_connection*, int, http_message*) + 203 (mongoose6.cxx:4947)
18 mhttpd 0x00000001003787c5 mg_http_handler(mg_connection*, int, void*) + 1365 (mongoose6.cxx:5141)
19 mhttpd 0x00000001003710db mg_call(mg_connection*, void (*)(mg_connection*, int, void*), int, void*) + 427 (mongoose6.cxx:2121)
20 mhttpd 0x00000001003730c8 mg_recv_common(mg_connection*, void*, int) + 312 (mongoose6.cxx:2677)
21 mhttpd 0x0000000100372f83 mg_if_recv_tcp_cb(mg_connection*, void*, int) + 35 (mongoose6.cxx:2681)
22 mhttpd 0x0000000100375d32 mg_read_from_socket(mg_connection*) + 514 (mongoose6.cxx:3379)
23 mhttpd 0x00000001003755f6 mg_mgr_handle_conn(mg_connection*, int, double) + 486
24 mhttpd 0x0000000100371b74 mg_mgr_poll + 1300 (mongoose6.cxx:3663)
25 mhttpd 0x0000000100382087 per_connection_thread_function(void*) + 71 (mongoose6.cxx:3804)
26 libsystem_pthread.dylib 0x00007fff746252eb _pthread_body + 126
27 libsystem_pthread.dylib 0x00007fff74628249 _pthread_start + 66
28 libsystem_pthread.dylib 0x00007fff7462440d thread_start + 13
Thread 5:
0 libsystem_kernel.dylib 0x00007fff7456d61a __select + 10
1 mhttpd 0x00000001003719ae mg_mgr_poll + 846 (mongoose6.cxx:3651)
2 mhttpd 0x0000000100382087 per_connection_thread_function(void*) + 71 (mongoose6.cxx:3804)
3 libsystem_pthread.dylib 0x00007fff746252eb _pthread_body + 126
4 libsystem_pthread.dylib 0x00007fff74628249 _pthread_start + 66
5 libsystem_pthread.dylib 0x00007fff7462440d thread_start + 13
Thread 6:
0 libsystem_kernel.dylib 0x00007fff7456d61a __select + 10
1 mhttpd 0x00000001003719ae mg_mgr_poll + 846 (mongoose6.cxx:3651)
2 mhttpd 0x0000000100382087 per_connection_thread_function(void*) + 71 (mongoose6.cxx:3804)
3 libsystem_pthread.dylib 0x00007fff746252eb _pthread_body + 126
4 libsystem_pthread.dylib 0x00007fff74628249 _pthread_start + 66
5 libsystem_pthread.dylib 0x00007fff7462440d thread_start + 13
Thread 4 crashed with X86 Thread State (64-bit):
rax: 0x0000000000000000 rbx: 0x000070000256e000 rcx: 0x000070000256c9f8 rdx: 0x0000000000000000
rdi: 0x0000000000000d07 rsi: 0x0000000000000006 rbp: 0x000070000256ca30 rsp: 0x000070000256c9f8
r8: 0x0000000000000000 r9: 0x000070000256c950 r10: 0x0000000000000000 r11: 0x0000000000000206
r12: 0x0000000000000d07 r13: 0x0000000100ee1000 r14: 0x0000000000000006 r15: 0x000000000000002d
rip: 0x00007fff7456c2c6 rfl: 0x0000000000000206 cr2: 0x000000072c967008
Logical CPU: 0
Error Code: 0x0200005d
Trap Number: 133
Binary Images:
0x10030c000 - 0x1004afff7 +mhttpd (0) <7F574F87-D453-37BF-B8C0-97FD8E8A6C84> /Users/USER/*/mhttpd
0x104f06000 - 0x104f7070f dyld (655.1.1) <DFC3C4AF-6F97-3B34-B18D-7DCB23F2A83A> /usr/lib/dyld
0x7fff6f14e000 - 0x7fff6f14ffff com.apple.TrustEvaluationAgent (2.0 - 31.200.1) <15DF9C73-54E4-3C41-BCF4-378338C55FB4> /System/Library/PrivateFrameworks/TrustEvaluationAgent.framework/Versions/A/TrustEvaluationAgent
0x7fff71418000 - 0x7fff71419ffb libSystem.B.dylib (1252.250.1) <B1006948-7AD0-3CA9-81E0-833F4DD6BFB4> /usr/lib/libSystem.B.dylib
0x7fff7165b000 - 0x7fff716aeff7 libc++.1.dylib (400.9.4) <9A60A190-6C34-339F-BB3D-AACE942009A4> /usr/lib/libc++.1.dylib
0x7fff716af000 - 0x7fff716c4ff7 libc++abi.dylib (400.17) <38C09CED-9090-3719-90F3-04A2749F5428> /usr/lib/libc++abi.dylib
0x7fff71b1a000 - 0x7fff71c12ff7 libcrypto.35.dylib (22.260.1) <91C3D71A-4D1D-331D-89CC-67863DF10574> /usr/lib/libcrypto.35.dylib
0x7fff72c4f000 - 0x7fff733d4fdf libobjc.A.dylib (756.2) <7C312627-43CB-3234-9324-4DEA92D59F50> /usr/lib/libobjc.A.dylib
0x7fff737e0000 - 0x7fff73813ff3 libssl.35.dylib (22.260.1) <EEBCC1DE-A2C2-30CC-AEA3-1B2193B11DAA> /usr/lib/libssl.35.dylib
0x7fff73abe000 - 0x7fff73ad0ff7 libz.1.dylib (70.200.4) <B048FC1F-058F-3A08-A1FE-81D5308CB3E6> /usr/lib/libz.1.dylib
0x7fff742b4000 - 0x7fff742b8ff3 libcache.dylib (81) <1987D1E1-DB11-3291-B12A-EBD55848E02D> /usr/lib/system/libcache.dylib
0x7fff742b9000 - 0x7fff742c3ff3 libcommonCrypto.dylib (60118.250.2) <1765BB6E-6784-3653-B16B-CB839721DC9A> /usr/lib/system/libcommonCrypto.dylib
0x7fff742c4000 - 0x7fff742cbff7 libcompiler_rt.dylib (63.4) <5212BA7B-B7EA-37B4-AF6E-AC4F507EDFB8> /usr/lib/system/libcompiler_rt.dylib
0x7fff742cc000 - 0x7fff742d5ff7 libcopyfile.dylib (146.250.1) <98CD00CD-9B91-3B5C-A9DB-842638050FA8> /usr/lib/system/libcopyfile.dylib
0x7fff742d6000 - 0x7fff7435afc3 libcorecrypto.dylib (602.260.2) <01464D24-570C-3B83-9D18-467769E0FCDD> /usr/lib/system/libcorecrypto.dylib
0x7fff743e1000 - 0x7fff7441aff7 libdispatch.dylib (1008.270.1) <97273678-E94C-3C8C-89F6-2E2020F4B43B> /usr/lib/system/libdispatch.dylib
0x7fff7441b000 - 0x7fff74447ff7 libdyld.dylib (655.1.1) <002418CC-AD11-3D10-865B-015591D24E6C> /usr/lib/system/libdyld.dylib
0x7fff74448000 - 0x7fff74448ffb libkeymgr.dylib (30) <0D0F9CA2-8D5A-3273-8723-59987B5827F2> /usr/lib/system/libkeymgr.dylib
0x7fff74456000 - 0x7fff74456ff7 liblaunch.dylib (1336.261.2) <2B07E27E-D404-3E98-9D28-BCA641E5C479> /usr/lib/system/liblaunch.dylib
0x7fff74457000 - 0x7fff7445cfff libmacho.dylib (927.0.3) <A377D608-77AB-3F6E-90F0-B4F251A5C12F> /usr/lib/system/libmacho.dylib
0x7fff7445d000 - 0x7fff7445fffb libquarantine.dylib (86.220.1) <6D0BC770-7348-3608-9254-F7FFBD347634> /usr/lib/system/libquarantine.dylib
0x7fff74460000 - 0x7fff74461ff7 libremovefile.dylib (45.200.2) <9FBEB2FF-EEBE-31BC-BCFC-C71F8D0E99B6> /usr/lib/system/libremovefile.dylib
0x7fff74462000 - 0x7fff74479ff3 libsystem_asl.dylib (356.200.4) <A62A7249-38B8-33FA-9875-F1852590796C> /usr/lib/system/libsystem_asl.dylib
0x7fff7447a000 - 0x7fff7447aff7 libsystem_blocks.dylib (73) <A453E8EE-860D-3CED-B5DC-BE54E9DB4348> /usr/lib/system/libsystem_blocks.dylib
0x7fff7447b000 - 0x7fff74502fff libsystem_c.dylib (1272.250.1) <7EDACF78-2FA3-35B8-B051-D70475A35117> /usr/lib/system/libsystem_c.dylib
0x7fff74503000 - 0x7fff74506ffb libsystem_configuration.dylib (963.270.3) <2B4A836D-68A4-33E6-8D48-CD4486B03387> /usr/lib/system/libsystem_configuration.dylib
0x7fff74507000 - 0x7fff7450aff7 libsystem_coreservices.dylib (66) <719F75A4-74C5-3BA6-A09E-0C5A3E5889D7> /usr/lib/system/libsystem_coreservices.dylib
0x7fff7450b000 - 0x7fff74511fff libsystem_darwin.dylib (1272.250.1) <EC9B39A5-9592-3577-8997-7DC721D20D8C> /usr/lib/system/libsystem_darwin.dylib
0x7fff74512000 - 0x7fff74518ff7 libsystem_dnssd.dylib (878.270.2) <E9A5ACCF-E35F-3909-AF0A-2A37CD217276> /usr/lib/system/libsystem_dnssd.dylib
0x7fff74519000 - 0x7fff74564ffb libsystem_info.dylib (517.200.9) <D09D5AE0-2FDC-3A6D-93EC-729F931B1457> /usr/lib/system/libsystem_info.dylib
0x7fff74565000 - 0x7fff7458dff7 libsystem_kernel.dylib (4903.271.2) <EA204E3C-870B-30DD-B4AF-D1BB66420D14> /usr/lib/system/libsystem_kernel.dylib
0x7fff7458e000 - 0x7fff745d9ff7 libsystem_m.dylib (3158.200.7) <F19B6DB7-014F-3820-831F-389CCDA06EF6> /usr/lib/system/libsystem_m.dylib
0x7fff745da000 - 0x7fff74604fff libsystem_malloc.dylib (166.270.1) <011F3AD0-8E6A-3A89-AE64-6E5F6840F30A> /usr/lib/system/libsystem_malloc.dylib
0x7fff74605000 - 0x7fff7460fff7 libsystem_networkextension.dylib (767.250.2) <FF06F13A-AEFE-3A27-A073-910EF78AEA36> /usr/lib/system/libsystem_networkextension.dylib
0x7fff74610000 - 0x7fff74617fff libsystem_notify.dylib (172.200.21) <145B5CFC-CF73-33CE-BD3D-E8DDE268FFDE> /usr/lib/system/libsystem_notify.dylib
0x7fff74618000 - 0x7fff74621fef libsystem_platform.dylib (177.270.1) <9D1FE5E4-EB7D-3B3F-A8D1-A96D9CF1348C> /usr/lib/system/libsystem_platform.dylib
0x7fff74622000 - 0x7fff7462cff7 libsystem_pthread.dylib (330.250.2) <2D5C08FF-484F-3D59-9132-CE1DCB3F76D7> /usr/lib/system/libsystem_pthread.dylib
0x7fff7462d000 - 0x7fff74630ff7 libsystem_sandbox.dylib (851.270.1) <9494594B-5199-3186-82AB-5FF8BED6EE16> /usr/lib/system/libsystem_sandbox.dylib
0x7fff74631000 - 0x7fff74633ff3 libsystem_secinit.dylib (30.260.2) <EF1EA47B-7B22-35E8-BD9B-F7003DCB96AE> /usr/lib/system/libsystem_secinit.dylib
0x7fff74634000 - 0x7fff7463bff3 libsystem_symptoms.dylib (820.267.1) <03F1C2DD-0F5A-3D9D-88F6-B26C0F94EB52> /usr/lib/system/libsystem_symptoms.dylib
0x7fff7463c000 - 0x7fff74651fff libsystem_trace.dylib (906.260.1) <FC761C3B-5434-3A52-912D-F1B15FAA8EB2> /usr/lib/system/libsystem_trace.dylib
0x7fff74653000 - 0x7fff74658ffb libunwind.dylib (35.4) <24A97A67-F017-3CFC-B0D0-6BD0224B1336> /usr/lib/system/libunwind.dylib
0x7fff74659000 - 0x7fff74688fff libxpc.dylib (1336.261.2) <7DEE2300-6D8E-3C00-9C63-E3E80D56B0C4> /usr/lib/system/libxpc.dylib
External Modification Summary:
Calls made by other processes targeting this process:
task_for_pid: 1
thread_create: 0
thread_set_state: 0
Calls made by this process:
task_for_pid: 0
thread_create: 0
thread_set_state: 0
Calls made by all processes on this machine:
task_for_pid: 402898
thread_create: 0
thread_set_state: 9
VM Region Summary:
ReadOnly portion of Libraries: Total=238.2M resident=0K(0%) swapped_out_or_unallocated=238.2M(100%)
Writable regions: Total=174.0M written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=174.0M(100%)
VIRTUAL REGION
REGION TYPE SIZE COUNT (non-coalesced)
=========== ======= =======
Kernel Alloc Once 8K 1
MALLOC 136.6M 15
Stack 67.1M 14
VM_ALLOCATE 12K 2
__DATA 3488K 44
__LINKEDIT 223.7M 3
__TEXT 14.5M 47
shared memory 1288K 5
=========== ======= =======
TOTAL 446.5M 131
|
|
1893
|
01 May 2020 |
Pierre Gorel | Forum | Taking MIDAS beyond 64 clients | > - On the other hand, if we have to break compatibility, now is maybe a good time since most accelerators worldwide are off. But before doing so, I would like to get feedback from the main experiments
> around the world (MEG, T2K, g-2, DEAP besides ALPHA).
Hello Stefan,
For what is worth, DEAP will not be impacted: as we have been taking data around the clock for the last few years, we froze the code running on the computers. We may have some window of opportunity for upgrade in few months but such a move has not been discussed yet.
Best regards,
Pierre |
|
2166
|
12 May 2021 |
Pierre Gorel | Bug Report | History formula not correctly managed | OS: OSX 10.14.6 Mojave
MIDAS: Downloaded from repo on April 2021.
I have a slow control frontend doing the command/readout of a MPOD HV/LV. Since I am reading out the current that are in nA (after updating snmp), I wanted to multiply the number by 1e9.
I noticed the new "Formula" field (introduced in 2019 it seems) instead of the "Factor/Offset" I was used to. None of my entries seems to be accepted (after hitting save, when coming back thee field is empty).
Looking in ODB in "/History/Display/MPOD/HV (Current)/", the field "Formula" is a string of size 32 (even if I have multiple plots in that display). I noticed that the fields "Factor" and "Offset" are still existing and they are arrays with the correct size. However, changing the values does not seem to do anything.
Deleting "Formula" by hand and creating a new field as an array of string (of correct length) seems to do the trick: the formula is displayed in the History display config, and correctly used. |
|
440
|
19 Feb 2008 |
Petr Nomokonov | Info | Frontend - Backend c onnection | Backend computer with SLC4.4 Linux did'not work as mserver because some security
protection under iptables service (could not connect with frontend computers).
The connection established if to make ( under root ) iptables disable
by command: service iptables stop, or much more gently
just to accept mserver port with command (under root):
iptables -I INPUT -p tcp --dport 1175 -j ACCEPT
( in /etc/service
midas 1175/tcp #Midas server)
To check which ports is open
it is possible to use the command: "netstat -n" to see digital numbers of ports. |
|
665
|
20 Oct 2009 |
Peter Simpson | Forum | Midas in linux | Hi,
I'm new to both Linux and Midas and having trouble installing the programme -
the install file suggeats that I should have a directory:
midas/unix
but this doesn't appear.
Also, when running the "make" for the library (step 3 of the installation), I
don't see the directory "zlib.a", but there is a "libz.a" and I note the
original .tar file has no libz.a file in it. Is this a typo on the
installation?
The terminal window at this point displays:
undefined reference to `errno'
make: ***[example] Error 1
Further help will no doubt be required as I've used windows throughout my
research and now looking to learn how to use linux. Any help greatly
appreciated. Thanks! |
|
1759
|
13 Jan 2020 |
Peter Kunz | Forum | cmake complie issues | While upgrading to the latest MIDAS version
MIDAS version: 2.1 GIT revision: Tue Dec 31 17:40:14 2019 +0100 - midas-2019-09-i-1-gd93944ce-dirty on branch develop
ODB version: 3
I encountered two issues using cmake
1. on machines with NVIDIA drivers:
nvml.h: no such file or directory
(nvml.h doesn't seem to be part of the standard nvidia driver package.)
2. Complile including ROOT throws an error with ROOT 6.12/06 on Centos7 and with ROOT 6.18/04 on Fedora 31:
[ 29%] Building CXX object CMakeFiles/rmana.dir/src/mana.cxx.o In file included from /usr/include/root/TString.h:28, from /usr/include/root/TCollection.h:29, from /usr/include/root/TSeqCollection.h:25, from /usr/include/root/TList.h:25, from /usr/include/root/TQObject.h:40, from /usr/include/root/TApplication.h:30, from /home/pkunz/packages/midas/src/mana.cxx:60:
/usr/include/root/ROOT/RStringView.hxx:32:37: error: ‘experimental’ in namespace ‘std’ does not name a type 32 | using basic_string_view = ::std::experimental::basic_string_view<_CharT,_Traits>;
A workaround (which works for me) is to compile with
cmake .. -DNO_ROOT=1 -DNO_NVIDIA=1 |
|
1760
|
13 Jan 2020 |
Peter Kunz | Forum | ODB dump format: json - events 0x8000 and 0x8001 missing | MIDAS version: 2.1
GIT revision: Tue Dec 31 17:40:14 2019 +0100 - midas-2019-09-i-1-gd93944ce-dirty on branch develop
/Logger/Channels/0/Settings
| ODB dump |
y |
| ODB dump format |
json |
With the settings above the file last.json generated for a new run is empty and the events 0x8000 and 0x8001 are missing in the .mid file.
When setting "ODB dump format" to "xml", events 0x8000 and 0x8001 are included in the .mid file, however, the file last.xml is not created.
|
|
1761
|
13 Jan 2020 |
Peter Kunz | Forum | frontend issues with midas-2019-09 | After upgrading to the lastes MIDAS version I got the DAQ frontend of my application running by changing all compiler directives from cc to g++ and using
#include "mfe.h"
extern HNDLE hDB
extern "C" {
#include <CAENComm.h>
}
With these changes everything seems to work fine.
However, I'm having trouble with a slow control frontend using a tcpip driver. It compiled well with the older MIDAS version. Even though all the functions in question are defined in the frontend code, the following error comes up:
g++ -o feMotor -DOS_LINUX -Dextname -g -O2 -fPIC -Wall -Wuninitialized -fpermissive -I/home/pkunz/packages/midas/include -I. -I/home/pkunz/packages/midas/drivers/bus /home/pkunz/packages/midas/lib/libmidas.a feMotor.o /home/pkunz/packages/midas/drivers/bus/tcpip.o cd_Galil.o /home/pkunz/packages/midas/lib/libmidas.a /home/pkunz/packages/midas/lib/mfe.o -lm -lz -lutil -lnsl -lpthread -lrt
/usr/bin/ld: /home/pkunz/packages/midas/lib/mfe.o: in function `initialize_equipment()':
/home/pkunz/packages/midas/src/mfe.cxx:687: undefined reference to `interrupt_configure(int, int, long)'
/usr/bin/ld: /home/pkunz/packages/midas/lib/mfe.o: in function `readout_enable(unsigned int)':
/home/pkunz/packages/midas/src/mfe.cxx:1236: undefined reference to `interrupt_configure(int, int, long)'
/usr/bin/ld: /home/pkunz/packages/midas/src/mfe.cxx:1238: undefined reference to `interrupt_configure(int, int, long)'
/usr/bin/ld: /home/pkunz/packages/midas/lib/mfe.o: in function `main':
/home/pkunz/packages/midas/src/mfe.cxx:2791: undefined reference to `interrupt_configure(int, int, long)'
/usr/bin/ld: /home/pkunz/packages/midas/src/mfe.cxx:2792: undefined reference to `interrupt_configure(int, int, long)'
collect2: error: ld returned 1 exit status
make: *** [Makefile:36: feMotor] Error 1
I guess the the aforementioned DAQ frontend compiles because its equipment definitions don't call on the function `initialize_equipment()', but I can't figure out why it doesn't work. Help is appreciated. P.K. |
|
1767
|
13 Jan 2020 |
Peter Kunz | Forum | frontend issues with midas-2019-09 | Thanks for explaining this, Konstantin.
After updating the function to
INT interrupt_configure(INT cmd, INT source, POINTER_T adr)
{
return CM_SUCCESS;
}
it compiled without errors. In the original code the "INT source" variable was missing.
> (please use the "plain" text, much easier to answer).
>
> Hi, Peter, I think you misread the error message. There is no error about initialize_equipment(), the error
> is about interrupt_configure(). initialize_equipment() is just one of the functions that calls it.
>
> The cause of the error most likely is a mismatch between the declaration of interrupt_configure() in
> mfe.h and the definition of this function in your program (in feMotor.c, I guess).
>
> Sometimes this mismatch is hard to identify just by looking at the code.
>
> One fool-proof method to debug this is to extract the actual function prototypes from your object files,
> both the declaration ("U") in mfe.o and the definition ("T") in your program should be identical:
>
> nm feMotor.o | grep -i interrupt | c++filt
> 0000000000000f90 T interrupt_configure(int, int, long) <--- should be this
>
> nm ~/packages/midas/lib/libmfe.a | grep -i interrupt | c++filt
> U interrupt_configure(int, int, long)
>
> If they are different, you adjust your program until they match. One way to ensure the match is to copy
> the declaration from mfe.h into your program.
>
> K.O.
>
>
>
>
> <p> </p>
>
> <table align="center" cellspacing="1" style="border:1px solid #486090; width:98%">
> <tbody>
> <tr>
> <td style="background-color:#486090">Peter Kunz wrote:</td>
> </tr>
> <tr>
> <td style="background-color:#FFFFB0">
> <p>After upgrading to the lastes MIDAS version I got the DAQ frontend of my application
> running by changing all compiler directives from cc to g++ and using</p>
>
> <p>#include "mfe.h"</p>
>
> <p>extern HNDLE hDB</p>
>
> <p> extern "C" { <br />
> #include <CAENComm.h> <br />
> }</p>
>
> <p>With these changes everything seems to work fine.</p>
>
> <p>However, I'm having trouble with a slow control frontend using a tcpip driver. It
> compiled well with the older MIDAS version. Even though all the functions in question are defined in the
> frontend code, the following error comes up:</p>
>
> <div style="background:#eee;border:1px solid #ccc;padding:5px 10px;">g++ -o feMotor
> -DOS_LINUX -Dextname -g -O2 -fPIC -Wall -Wuninitialized -fpermissive -
> I/home/pkunz/packages/midas/include -I. -I/home/pkunz/packages/midas/drivers/bus
> /home/pkunz/packages/midas/lib/libmidas.a feMotor.o
> /home/pkunz/packages/midas/drivers/bus/tcpip.o cd_Galil.o
> /home/pkunz/packages/midas/lib/libmidas.a /home/pkunz/packages/midas/lib/mfe.o -lm -lz -lutil -lnsl -
> lpthread -lrt<br />
> /usr/bin/ld: /home/pkunz/packages/midas/lib/mfe.o: in function
> `initialize_equipment()':<br />
> /home/pkunz/packages/midas/src/mfe.cxx:687: undefined reference to
> `interrupt_configure(int, int, long)'<br />
> /usr/bin/ld: /home/pkunz/packages/midas/lib/mfe.o: in function
> `readout_enable(unsigned int)':<br />
> /home/pkunz/packages/midas/src/mfe.cxx:1236: undefined reference to
> `interrupt_configure(int, int, long)'<br />
> /usr/bin/ld: /home/pkunz/packages/midas/src/mfe.cxx:1238: undefined reference to
> `interrupt_configure(int, int, long)'<br />
> /usr/bin/ld: /home/pkunz/packages/midas/lib/mfe.o: in function `main':<br />
> /home/pkunz/packages/midas/src/mfe.cxx:2791: undefined reference to
> `interrupt_configure(int, int, long)'<br />
> /usr/bin/ld: /home/pkunz/packages/midas/src/mfe.cxx:2792: undefined reference to
> `interrupt_configure(int, int, long)'<br />
> collect2: error: ld returned 1 exit status<br />
> make: *** [Makefile:36: feMotor] Error 1</div>
>
> <p> I guess the the aforementioned DAQ frontend compiles because its equipment
> definitions don't call on the function `initialize_equipment()', but I can't figure out why
> it doesn't work. Help is appreciated. P.K.</p>
> </td>
> </tr>
> </tbody>
> </table>
>
> <p> </p> |
|
1768
|
13 Jan 2020 |
Peter Kunz | Forum | ODB dump format: json - events 0x8000 and 0x8001 missing | Re: MIDAS versions
Thanks for pointing that out. I wasn't actually aware that there is a release branch and a development branch.
I was just following the installation instructions using
git clone https://bitbucket.org/tmidas/midas --recursive
Apparently that gave me the development branch. How can I get the release version?
(I think my version showed up a "dirty" because I played around with one of the examples. I didn't touch the actual source code.)
> (Please post messages in "plain" mode, they are much easier to answer)
>
> Thank you for reporting this problem. I will try to reproduce it.
>
> In addition, I will say a few words about your version of midas:
>
> > GIT revision: midas-2019-09-i-1-gd93944ce-dirty on branch develop
>
> I recommend that for production systems one used the tagged release versions of midas.
> (i.e. see https://midas.triumf.ca/elog/Midas/1750).
>
> (Your midas is "1 commit after the latest tag" - the "-1" in the git revision).
>
> I apply bug fixes to both the release branch and the develop branch, but for you to get
> these fixes, on the develop branch you will also "get" all the unrelated changes that may
> come with new bugs. On the release branch, you will only get the bug fixes.
>
> In your midas version it says "-dirty" which means that you have local modifications to the
> midas sources. With luck those changes are not related to the bug that you see. (but I
> cannot tell). You can do "git status" and "git diff" to see what the local changes are.
>
> It is much better if bugs are reported against "clean" builds of MIDAS (no "-dirty").
>
>
> K.O.
>
>
> <p> </p>
>
> <table align="center" cellspacing="1" style="border:1px solid #486090; width:98%">
> <tbody>
> <tr>
> <td style="background-color:#486090">Peter Kunz wrote:</td>
> </tr>
> <tr>
> <td style="background-color:#FFFFB0">
> <p>MIDAS version: 2.1<br />
> GIT revision: Tue Dec 31 17:40:14 2019 +0100 -
> midas-2019-09-i-1-gd93944ce-dirty on branch develop</p>
>
> <p>/Logger/Channels/0/Settings</p>
>
> <table border="3" cellpadding="1" class="dialogTable">
> <tbody>
> <tr>
> <td>ODB dump</td>
> <td>y</td>
> </tr>
> <tr>
> <td>ODB dump format</td>
> <td>json</td>
> </tr>
> </tbody>
> </table>
>
> <p>With the settings above the file last.json generated for a new run is
> empty and the events 0x8000 and 0x8001 are missing in the .mid file.</p>
>
> <p>When setting "ODB dump format" to "xml", events
> 0x8000 and 0x8001 are included in the .mid file, however, the file last.xml is not created.
> </p>
>
> <p> </p>
>
> <p> </p>
>
> <p> </p>
> </td>
> </tr>
> </tbody>
> </table>
>
> <p> </p> |
|
1770
|
13 Jan 2020 |
Peter Kunz | Forum | cmake complie issues | Re: ROOT problem
I looked into how my ROOT based MIDAS analyzer compiles. It is using the flag -std=c++14.
MIDAS cmake compiles with -std=gnu++11 with the result:
29%] Building CXX object CMakeFiles/rmana.dir/src/mana.cxx.o
/usr/bin/c++ -D_LARGEFILE64_SOURCE -I/home/pkunz/packages/midas/include -I/home/pkunz/packages/midas/mxml -I/usr/include/root -O2 -g -DNDEBUG -DHAVE_ZLIB -DHAVE_FTPLIB -Wall -Wformat=2 -Wno-format-nonliteral -Wno-strict-aliasing -Wuninitialized -Wno-unused-function -DHAVE_ROOT -std=gnu++11 -o CMakeFiles/rmana.dir/src/mana.cxx.o -c /home/pkunz/packages/midas/src/mana.cxx
In file included from /usr/include/root/TString.h:28,
from /usr/include/root/TCollection.h:29,
from /usr/include/root/TSeqCollection.h:25,
from /usr/include/root/TList.h:25,
from /usr/include/root/TQObject.h:40,
from /usr/include/root/TApplication.h:30,
from /home/pkunz/packages/midas/src/mana.cxx:60:
/usr/include/root/ROOT/RStringView.hxx:32:37: error: ‘experimental’ in namespace ‘std’ does not name a type
32 | using basic_string_view = ::std::experimental::basic_string_view<_CharT,_Traits>;
If I change this to
/usr/bin/c++ -D_LARGEFILE64_SOURCE -I/home/pkunz/packages/midas/include -I/home/pkunz/packages/midas/mxml -I/usr/include/root -O2 -g -DNDEBUG -DHAVE_ZLIB -DHAVE_FTPLIB -Wall -Wformat=2 -Wno-format-nonliteral -Wno-strict-aliasing -Wuninitialized -Wno-unused-function -DHAVE_ROOT -std=c++14 -o CMakeFiles/rmana.dir/src/mana.cxx.o -c /home/pkunz/packages/midas/src/mana.cxx
it compiles without error. I hope this helps.
> (please post messages in "plain" mode, they are much easier to answer)
>
> - nvidia problems - this code was contributed by Joseph (I think?), with luck he will look into
> this problem.
>
> - ROOT problem - it looks like the error is thrown by the ROOT header files, has nothing to do
> with MIDAS?
>
> So what ROOT are you using? I recommend installing ROOT by following instructions at
> root.cern.ch.
>
> Perhaps you used the ROOT packages from the EPEL repository? I have seen trouble with
> those packages before (miscompiled; important optional features turned off; very old
> versions; etc).
>
> P.S.
>
> Historically, ROOT has caused so many reports of "cannot build midas" that I consistently
> vote to "remove ROOT support from MIDAS". But Stefan's code for writing MIDAS data into
> ROOT files is so neat, cannot throw it away. And some people do use it. So at the latest MIDAS
> bash this Summer we decided to keep it.
>
> (Only build targets to use ROOT are the rmlogger executable and the rmana.o object file (and
> it's one-man-army library)).
>
> But.
>
> In the past, one could use "make -k" to get past the errors caused by ROOT, everything will
> get built and installed, except for the code that failed to build.
>
> Now with cmake, it is "all or nothing", if there is any compilation error, nothing gets installed
> into the "bin" directory. So one must discover and use "NO_ROOT=1" (which becomes sticky
> until the next "make cclean". Some people are not used to sticky "make" options, I just got
> burned by this very thing last week).
>
> Perhaps there is a way to tell cmake to ignore compile errors for rmlogger and rmana.
>
>
> K.O.
>
>
>
> <p> </p>
>
> <table align="center" cellspacing="1" style="border:1px solid #486090; width:98%">
> <tbody>
> <tr>
> <td style="background-color:#486090">Peter Kunz wrote:</td>
> </tr>
> <tr>
> <td style="background-color:#FFFFB0">
> <p>While upgrading to the latest MIDAS version</p>
>
> <p>MIDAS version: 2.1 GIT revision: Tue Dec 31 17:40:14 2019 +0100 - midas-
> 2019-09-i-1-gd93944ce-dirty on branch develop</p>
>
> <p>ODB version: 3</p>
>
> <p>I encountered two issues using cmake</p>
>
> <p>1. on machines with NVIDIA drivers:</p>
>
> <div style="background:#eee;border:1px solid #ccc;padding:5px
> 10px;">nvml.h: no such file or directory</div>
>
> <p>(nvml.h doesn't seem to be part of the standard nvidia driver
> package.)</p>
>
> <p>2. Complile including ROOT throws an error with ROOT 6.12/06 on Centos7
> and with ROOT 6.18/04 on Fedora 31:</p>
>
> <div style="background:#eee;border:1px solid #ccc;padding:5px 10px;">[ 29%]
> Building CXX object CMakeFiles/rmana.dir/src/mana.cxx.o In file included from
> /usr/include/root/TString.h:28, from /usr/include/root/TCollection.h:29, from
> /usr/include/root/TSeqCollection.h:25, from /usr/include/root/TList.h:25, from
> /usr/include/root/TQObject.h:40, from /usr/include/root/TApplication.h:30, from
> /home/pkunz/packages/midas/src/mana.cxx:60:</div>
>
> <div style="background:#eee;border:1px solid #ccc;padding:5px
> 10px;">/usr/include/root/ROOT/RStringView.hxx:32:37: error: ‘experimental’ in
> namespace ‘std’ does not name a type 32 | using basic_string_view =
> ::std::experimental::basic_string_view<_CharT,_Traits>;</div>
>
> <p>A workaround (which works for me) is to compile with</p>
>
> <p><tt>cmake .. -DNO_ROOT=1 -DNO_NVIDIA=1</tt></p>
> </td>
> </tr>
> </tbody>
> </table>
>
> <p> </p> |
|
1777
|
14 Jan 2020 |
Peter Kunz | Forum | EPICS frontend does not compile under midas-2019-09-i | I'm still trying to upgrade my MIDAS system to midas-2019-09-i. Most frontends work fine with the modifications already discussed.
However, I ran into some trouble with the epics frontend. Even with the modifications it throws a lot of warnings and errors (see attached log file). I can reduce the errors with -fpermissive, but the following two errors are persistent:
/home/ays/packages/midas/drivers/device/epics_ca.cxx:167:38: error: ‘ca_create_channel’ was not declared in this scope
, &(info->caid[i].chan_id))
/home/ays/packages/midas/drivers/device/epics_ca.cxx:178:37: error: ‘ca_create_subscription’ was not declared in this scope
, &(info->caid[i].evt_id))
This is strange because the functions seem to be declared in base/include/cadef.h along with similar functions that don't throw an error.
I don't know what's going on. The frontend which is almost identical to the example in the midas distribution compiles without warnings or errors under the Midas2017 version. |
| Attachment 1: epics_compile_errors.txt
|
[ays@isys05 epics]$ make
g++ -g -D_POSIX_C_SOURCE=199506L -D_POSIX_THREADS -D_XOPEN_SOURCE=500 -DOSITHREAD_USE_DEFAULT_STACK -D_X86_ -DUNIX -D_BSD_SOURCE -Dlinux -I. -I/home/ays/packages/midas/include -I/home/ays/packages/midas/drivers -I/home/ays/packages/base/include -I/home/ays/packages/base/include/os/Linux/ -DOS_LINUX -c /home/ays/packages/midas/drivers/device/epics_ca.cxx -o epics_ca.o
In file included from /home/ays/packages/midas/drivers/device/epics_ca.cxx:29:0:
/home/ays/packages/midas/include/midas.h:1316:21: warning: non-static data member initializers only available with -std=c++11 or -std=gnu++11 [enabled by default]
DWORD event_id = 0;
^
/home/ays/packages/midas/include/midas.h:1318:18: warning: non-static data member initializers only available with -std=c++11 or -std=gnu++11 [enabled by default]
DWORD n_tag = 0;
^
/home/ays/packages/midas/include/midas.h:1323:19: warning: non-static data member initializers only available with -std=c++11 or -std=gnu++11 [enabled by default]
int hist_fh = 0;
^
/home/ays/packages/midas/include/midas.h:1324:19: warning: non-static data member initializers only available with -std=c++11 or -std=gnu++11 [enabled by default]
int index_fh = 0;
^
/home/ays/packages/midas/include/midas.h:1325:19: warning: non-static data member initializers only available with -std=c++11 or -std=gnu++11 [enabled by default]
int def_fh = 0;
^
/home/ays/packages/midas/include/midas.h:1326:23: warning: non-static data member initializers only available with -std=c++11 or -std=gnu++11 [enabled by default]
DWORD base_time = 0;
^
/home/ays/packages/midas/include/midas.h:1327:23: warning: non-static data member initializers only available with -std=c++11 or -std=gnu++11 [enabled by default]
DWORD def_offset = 0;
^
/home/ays/packages/midas/drivers/device/epics_ca.cxx: In function ‘void exceptionCallback(exception_handler_args)’:
/home/ays/packages/midas/drivers/device/epics_ca.cxx:64:25: warning: deprecated conversion from string constant to ‘char*’ [-Wwrite-strings]
static char *noname = "unknown";
^
/home/ays/packages/midas/drivers/device/epics_ca.cxx:69:50: warning: deprecated conversion from string constant to ‘char*’ [-Wwrite-strings]
if(chid) printChidInfo(chid,"exceptionCallback");
^
/home/ays/packages/midas/drivers/device/epics_ca.cxx: In function ‘void connectionCallback(connection_handler_args)’:
/home/ays/packages/midas/drivers/device/epics_ca.cxx:78:42: warning: deprecated conversion from string constant to ‘char*’ [-Wwrite-strings]
printChidInfo(chid,"connectionCallback");
^
/home/ays/packages/midas/drivers/device/epics_ca.cxx: In function ‘void accessRightsCallback(access_rights_handler_args)’:
/home/ays/packages/midas/drivers/device/epics_ca.cxx:85:44: warning: deprecated conversion from string constant to ‘char*’ [-Wwrite-strings]
printChidInfo(chid,"accessRightsCallback");
^
/home/ays/packages/midas/drivers/device/epics_ca.cxx: In function ‘INT epics_ca_init(HNDLE, void**, INT)’:
/home/ays/packages/midas/drivers/device/epics_ca.cxx:133:35: error: invalid conversion from ‘void*’ to ‘CA_INFO*’ [-fpermissive]
info = calloc(1, sizeof(CA_INFO));
^
/home/ays/packages/midas/drivers/device/epics_ca.cxx:139:57: error: invalid conversion from ‘void*’ to ‘char*’ [-fpermissive]
info->channel_names = calloc(channels, CHN_NAME_LENGTH);
^
/home/ays/packages/midas/drivers/device/epics_ca.cxx:153:47: error: invalid conversion from ‘void*’ to ‘float*’ [-fpermissive]
info->array = calloc(channels, sizeof(float));
^
In file included from /home/ays/packages/midas/drivers/device/epics_ca.cxx:19:0:
./cadef.h:762:12: warning: deprecated conversion from string constant to ‘char*’ [-Wwrite-strings]
__LINE__); \
^
/home/ays/packages/midas/drivers/device/epics_ca.cxx:160:3: note: in expansion of macro ‘SEVCHK’
SEVCHK(ca_add_exception_event(exceptionCallback,NULL), "ca_add_exception_event");
^
./cadef.h:762:12: warning: deprecated conversion from string constant to ‘char*’ [-Wwrite-strings]
__LINE__); \
^
/home/ays/packages/midas/drivers/device/epics_ca.cxx:160:3: note: in expansion of macro ‘SEVCHK’
SEVCHK(ca_add_exception_event(exceptionCallback,NULL), "ca_add_exception_event");
^
/home/ays/packages/midas/drivers/device/epics_ca.cxx:167:38: error: ‘ca_create_channel’ was not declared in this scope
, &(info->caid[i].chan_id))
^
./cadef.h:756:32: note: in definition of macro ‘SEVCHK’
int ca_unique_status_name = (CA_ERROR_CODE); \
^
./cadef.h:762:12: warning: deprecated conversion from string constant to ‘char*’ [-Wwrite-strings]
__LINE__); \
^
/home/ays/packages/midas/drivers/device/epics_ca.cxx:163:5: note: in expansion of macro ‘SEVCHK’
SEVCHK(ca_create_channel(info->channel_names + CHN_NAME_LENGTH * i
^
./cadef.h:762:12: warning: deprecated conversion from string constant to ‘char*’ [-Wwrite-strings]
__LINE__); \
^
/home/ays/packages/midas/drivers/device/epics_ca.cxx:163:5: note: in expansion of macro ‘SEVCHK’
SEVCHK(ca_create_channel(info->channel_names + CHN_NAME_LENGTH * i
^
./cadef.h:762:12: warning: deprecated conversion from string constant to ‘char*’ [-Wwrite-strings]
__LINE__); \
^
/home/ays/packages/midas/drivers/device/epics_ca.cxx:169:5: note: in expansion of macro ‘SEVCHK’
SEVCHK(ca_replace_access_rights_event(info->caid[i].chan_id
^
./cadef.h:762:12: warning: deprecated conversion from string constant to ‘char*’ [-Wwrite-strings]
__LINE__); \
^
/home/ays/packages/midas/drivers/device/epics_ca.cxx:169:5: note: in expansion of macro ‘SEVCHK’
SEVCHK(ca_replace_access_rights_event(info->caid[i].chan_id
^
/home/ays/packages/midas/drivers/device/epics_ca.cxx:178:37: error: ‘ca_create_subscription’ was not declared in this scope
, &(info->caid[i].evt_id))
^
./cadef.h:756:32: note: in definition of macro ‘SEVCHK’
int ca_unique_status_name = (CA_ERROR_CODE); \
^
./cadef.h:762:12: warning: deprecated conversion from string constant to ‘char*’ [-Wwrite-strings]
__LINE__); \
^
/home/ays/packages/midas/drivers/device/epics_ca.cxx:172:5: note: in expansion of macro ‘SEVCHK’
SEVCHK(ca_create_subscription (DBR_FLOAT
^
./cadef.h:762:12: warning: deprecated conversion from string constant to ‘char*’ [-Wwrite-strings]
__LINE__); \
^
/home/ays/packages/midas/drivers/device/epics_ca.cxx:172:5: note: in expansion of macro ‘SEVCHK’
SEVCHK(ca_create_subscription (DBR_FLOAT
^
./cadef.h:762:12: warning: deprecated conversion from string constant to ‘char*’ [-Wwrite-strings]
__LINE__); \
^
/home/ays/packages/midas/drivers/device/epics_ca.cxx:186:3: note: in expansion of macro ‘SEVCHK’
SEVCHK(ca_pend_event(5.0), "ca_ped_event");
^
./cadef.h:762:12: warning: deprecated conversion from string constant to ‘char*’ [-Wwrite-strings]
__LINE__); \
^
/home/ays/packages/midas/drivers/device/epics_ca.cxx:186:3: note: in expansion of macro ‘SEVCHK’
SEVCHK(ca_pend_event(5.0), "ca_ped_event");
^
/home/ays/packages/midas/drivers/device/epics_ca.cxx: In function ‘INT epics_ca(INT, ...)’:
/home/ays/packages/midas/drivers/device/epics_ca.cxx:308:50: error: invalid conversion from ‘void*’ to ‘void**’ [-fpermissive]
status = epics_ca_init(hKey, pinfo, channel);
^
/home/ays/packages/midas/drivers/device/epics_ca.cxx:126:5: error: initializing argument 2 of ‘INT epics_ca_init(HNDLE, void**, INT)’ [-fpermissive]
INT epics_ca_init(HNDLE hKey, void **pinfo, INT channels)
^
In file included from ./cadef.h:95:0,
from /home/ays/packages/midas/drivers/device/epics_ca.cxx:19:
/home/ays/packages/midas/drivers/device/epics_ca.cxx:312:29: error: invalid conversion from ‘void*’ to ‘CA_INFO*’ [-fpermissive]
info = va_arg(argptr, void *);
^
make: *** [epics_ca.o] Error 1
[ays@isys05 epics]$
|
|
1780
|
15 Jan 2020 |
Peter Kunz | Forum | EPICS frontend does not compile under midas-2019-09-i | Hi Konstantin,
I have EPICS Base Release 3.14.8.2 and got your example running with it, though I had to make one change.
For some reason it wouldn't find libca.so, but when I linked the static library libca.a instead, it worked.
Also my midas frontend works now with the updated epics_ca.xx. There was a problem with an old local version of cadef.h
(probably a leftover from some previous testing). After removing it everything compiled well.
Thanks,
Peter
> I fixed the compiler errors in epics_ca.cxx, can you try again? (see https://bitbucket.org/tmidas/midas/commits/)
>
> But, I do not see errors with ca_create_channel() and ca_create_subscription().
>
> Maybe I am using the wrong epics. If you still see these errors, let me know what epics you have, I will try the same one.
>
> This is what I do (and I get epics 7.0).
>
> mkdir -p $HOME/git
> cd $HOME/git
> git clone https://git.launchpad.net/epics-base
> cd epics-base
> make
> ls -l include/cadef.h
> ls -l lib/darwin-x86/libca.a # also linux-x86/libca.a
>
> K.O.
>
> > > I'm still trying to upgrade my MIDAS system to midas-2019-09-i. Most frontends work fine with the modifications already discussed.
> > > However, I ran into some trouble with the epics frontend. Even with the modifications it throws a lot of warnings and errors (see attached log file). I can reduce the errors with -fpermissive, but the following two errors are persistent:
> > >
> > > /home/ays/packages/midas/drivers/device/epics_ca.cxx:167:38: error: ‘ca_create_channel’ was not declared in this scope
> > > , &(info->caid[i].chan_id))
> > >
> > > /home/ays/packages/midas/drivers/device/epics_ca.cxx:178:37: error: ‘ca_create_subscription’ was not declared in this scope
> > > , &(info->caid[i].evt_id))
> > >
> > > This is strange because the functions seem to be declared in base/include/cadef.h along with similar functions that don't throw an error.
> > > I don't know what's going on. The frontend which is almost identical to the example in the midas distribution compiles without warnings or errors under the Midas2017 version.
> >
> > Hi, Peter - it looks like epics_ca.cxx needs to be updated to proper C++ (char* warnings, etc).
> >
> > As for the "function not declared" errors, it's the C++ way to say "you are calling a function with wrong arguments",
> > again, something I should be able to fix without too much trouble.
> >
> > Thank you for reporting this, the midas version of epics_ca.cxx definitely needs fixing.
> >
> > K.O. |
|
2267
|
31 Jul 2021 |
Peter Kunz | Bug Report | ss_shm_name: unsupported shared memory type, bye! | I ran into a problem trying to compile the latest MIDAS version on a Fedora
system.
mhttpd and odbedit return:
ss_shm_name: unsupported shared memory type, bye!
check_shm_type: preferred POSIXv4_SHM got SYSV_SHM
The check returns SYSV_SHM which doesn't seem to be supported in ss_shm_name.
Is there an easy solution for this?
Thanks. |
|
1115
|
23 Sep 2015 |
Peter Kravtsov | Forum | db_paste_node error in offline analyzer | I have a problem with using analyzer offline.
I'm trying to do it this way:
[lkst@pklinux online]$ kill_daq.sh
[lkst@pklinux online]$ odbedit -c "load data/run00020.odb"
[ODBEdit,INFO] Reloading RPC hosts access control list via hotlink callback
[lkst@pklinux online]$ analyzer -i data/run00020.mid -o test20.root
Root server listening on port 9090...
Running analyzer offline. Stop with "!"
[Analyzer,INFO] Set run number 20 in ODB
analyzer: src/odb.c:6631: db_paste_node: Assertion `status == 1' failed.
Load ODB from run 20...Aborted
[lkst@pklinux online]$
I always get this "Assertion `status == 1' failed." error even
if I try it in the examples/experiment enclosed in MIDAS distribution.
After this try I can not run any midas program, even odbedit reports an error,
until I delete the ODB file in /dev/shm/ and load last ODB dump with odbedit.
What do I do wrong and how this can be fixed? |
|
2633
|
22 Nov 2023 |
Pavel Murat | Forum | run number from an external (*SQL) db? | Dear MIDAQ developers,
I wonder if there is a non-intrusive way to have an external (wrt MIDAS)*SQL database
serving as a primary source of the run number information for a MIDAS-based DAQ system?
- like a plugin with a getNextRunNumber() function, for example, or a special client?
Here is the use case:
- multiple subdetectors are taking test data during early commissioning
- a postgres db is a single sorce of run numbers.
- test runs taken by different subsystems are assigned different [unique] run numbers and
the data taken by the subsystem are identified not by the run number/dataset name , but
by the run type, different for different susbsystems.
-- many thanks, regards, Pasha |
|
2636
|
01 Dec 2023 |
Pavel Murat | Forum | run number from an external (*SQL) db? | > > - multiple subdetectors are taking test data during early commissioning
> > - a postgres db is a single sorce of run numbers.
> > - test runs taken by different subsystems are assigned different [unique] run numbers and
> > the data taken by the subsystem are identified not by the run number/dataset name , but
> > by the run type, different for different susbsystems.
>
> For that purpose I would not "mis-use" run numbers. Run number are meant to be incremented
> sequentially, like if you have a time-stamp in seconds since 1.1.1970 (Unix time). Intead, I
> would add additional attributes under /Experiment/Run Parameters like "Subsystem type", "Run
> mode (production/commissioning)" etc. You have much more freedom in choosing any number of
> attributes there. Then, send this attributes to your postgred db via "/Logger/Runlog/SQL/Links
> BOR". Then you can query your database to give you all runs of a certain subtype or mode.
>
> See https://daq00.triumf.ca/MidasWiki/index.php/Logging_to_a_mySQL_database
>
> Stefan
Ben, Stefan - thanks much for your suggestions!(and apologies for the thanks being delayed)
Stefan, I don't think we're talking 'mis-use' - rather different subdetectors being commisisoned
at different locations, on an uncorrelated schedule, using independent run control (RC) instances.
At this point in time, we can't use a common RC instance.
The collected data, however, are written back into a common storage, and we need to avoid two
subdetectors using the same run number. As all RC instances can connect to the same database and request a
run number from there, an external DB serving run numbers to multiple clients looks as a reasonable solution,
which provides unique run numbers for everyone. Of course, the run number gets incremented (although on the DB
server side), and of course different susbystems are assigned different subsystem types.
So, in essense, it is about _where_ the run number is incremented - the RC vs the DB.
If there were a good strategy to implement a DB-based solution that w/o violating
first principles of Midas:), I'd be happy to contribute. It looks like a legitimate use case.
-- let me know, regards, Pasha |
|
2637
|
01 Dec 2023 |
Pavel Murat | Forum | MIDAS state machine : how to get around w/o 'configured' state? | I have one more question, though I understand that it could be somewhat border-line.
The MIDAS state machine doesn't seem to have a state in between 'initialized' and
'running'.
In a larger detectors with multiple subsystems, the DAQ systems often have one more state:
after ending a previous run and before starting a new one from the 'stopped' state,
one needs to make sure that all subdetectors are ready, or 'configured' for the new run.
So theat calls for a 'configure' step during which the detector (all subsystems in
parallel, to save the time) transitions from 'initialized'/'stopped' to 'configured' state,
from which it transitions to the 'running' state.
If one of the subdetectors fails to get configured, it could be excluded from the run
configuration and another attempt to reconfigure the system could be made without
starting a new run. Or an attempt could be made to troubleshoot and configure the
failed subsytem individually , with the rest subsystems waiting in a 'configured' state.
How does the logic of configuring the detector for the new run is implemented in MIDAS?
- it is a fairly common operational procedure, so I'm sure there should be a way
of doing that.
-- thanks again, Pasha |
|
2640
|
02 Dec 2023 |
Pavel Murat | Forum | run number from an external (*SQL) db? | >
> If you go in this direction, there is an alternative to what Ben wrote: Use the sequencer to start a run.
> The sequencer script can obtain a new run number from a central instance (e.g. by calling a shell script
> like 'curl ...' to obtain the new run number, then put it into /Runinfo/Run number as Ben wrote. This has
> the advantage that the run is _started_ already with the correct number, so the history system is fine.
>
Hi Stefan, this sounds like a perfect solution - thanks! - and leads to another, more technical, question:
- how does one communicate with an external shell script from MSL ? I looked at the MIDAS Sequencer page
https://daq00.triumf.ca/MidasWiki/index.php/Sequencer
and didn't find an immediately obvious candidate among the MSL commands.
The closest seems to be
'SCRIPT script [, a, b, c, ...]'
but I couldn't easily figure how to propagate the output of the script back to MIDAS.
Let say, the script creates an ASCII file with the next run number. What is the easiest
way to import the run number into ODB? - Should an external script spawn a [short-lived]
MIDAS client ? - That would work, but I'm almost sure there is a more straightforward solution.
Of course, the assumption that the 'SCRIPT' command provides the solution could be wrong.
-- thanks again, regards, Pasha |
|
2641
|
02 Dec 2023 |
Pavel Murat | Forum | MIDAS state machine : how to get around w/o 'configured' state? | > - To start a run, we start a special sequencer script. We have different scripts for
> calibration runs, data runs, special runs.
>
a sequencer-based way sounds like a very good solution, which provides all needed functionality
and even more flexibility than a state machine transition. Will give it a try.
-- thanks again, regards, Pasha |
|