ELOG Midas

Back Midas Rome Roody Rootana

Midas DAQ System, Page 57 of 152

Not logged in

Find | Login | Help

Full | Summary | Threaded | Hide attachments

3026 Entries

Goto page Previous 1, 2, 3 ... 56, 57, 58 ... 150, 151, 152 Next

While I know some of those limits/problems have been already been reported from
DEAP (and maybe corrected in the last version), I am recording them here:

Bugs (not working as it should): 
- "SCRIPT" does not seem to take the parameters into account
- The operators for WAIT are incorrectly set:
the default ">=" and ">" are correct, but "<=", "<", "==" and "!=" are all using
">=" for the test. 

Possible improvements:
- in LOOP, how can I get the index of the LOOP? I used an extra variable that I
increment, but it there a better way?
- PARAM is giving "string" (or a bool) whose size is set by the user input. The
side effect is that if I am making a loop starting at "1", the incrementation
will loop at "9" -> "1". If I start at "01", the incrementation will give "2.",
"3.",... "9.", "10"... The later is probably what most people would use.
- ODBGet (and ODBSet?) does seem to be able to take a variable as a path... I
was trying to use an array whose index would be incremented.

badly managed case in history_schema.cxx: dat file empty

For an unknown reason, Logger died few days ago while writing the history. The
file mhf_1489577446_20170315_system.dat was created, but was empty.

When trying to restart Logger, I would get a seg fault without any special error
message.

I tracked the issue to the "read_file_schema" function in history_schema.cxx

* L4731, a pointer to HsFileSchema *s is declared.
* L4747, We enter a while(1) loop.
* L4749, get char on the filename.
In our case, the file was empty, so the variable "b" gets NULL and the loop breaks.

Problem: the memory allocation for "s" is later in the loop, L4768.
Upon exiting the loop, L4854, we try to access record_size on a NULL pointer ==>
SegFault. 

It would be nice to at least have a message before breaking the loop...

> Hi everyone, 
> 
> We have recently been experiencing a lot of lag with our midas control webpage,
> which is making it very frustrating to use. Has anyone experienced this, and do
> you have any advice to speed it up? Are there particular web browsers that work
> better than others, or certain settings that can make respond more quickly?
> 
> Thanks!
> Wes

We saw this happening as well. In our case, we could track this down to mhttpd
taking a lot of CPU. A kill/restart of mhttpd is usually doing the trick (without
disturbing data taking). We did not find an obvious reason for this happening.

Launching an executable script from the sequencer

> Dear experts,
>               is there any way to launch an executable script on the host computer from the MIDAS 
> sequencer? If not, is there any interest to develop such a feature?
> 
> Thank you,
>          Francesco

The SCRIPT command will do that (on the machine running MIDAS). I know it works with either python or
bash scripts. I tried without success to pass the parameters and I went around by setting ODB entries
prior to running the script and then access to them within the script.

> 
> .... some ODB settings ....
>      TRANSITION START
>      WAIT events 100
>      TRANSITION STOP
> I have two questions: 
> 
> - for the long run, I want to write on disk only a maximum number of events. I think I can suppress 
> the event polling in the frontend, with an ODB query of the number of collected events. I'm 
> wondering if there is a smarter way to do that. It is also ok if the run is stopped after a maximum 
> number of events, but the subsequent short run should still start exactly after 1h from the previous 
> short run. 

I don't know about a way to give you an exact number of events (maybe /Logger/Run duration). 

I personally use 
    WAIT ODBValue,"/Equipment/DTM/Statistics/Events sent",>,100

Where DTM is the frontend of my trigger. Because of the lag in the run stop, the run will always exceed by few
seconds*rates.

Hope it helps

Newly installed MIDAS on OSX: mhttpd crahes

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))

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

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

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.

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.

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!

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

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.

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.

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>&nbsp;</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 &quot;mfe.h&quot;</p>
> 
> 			<p>extern HNDLE hDB</p>
> 
> 			<p>&nbsp;extern &quot;C&quot; {&nbsp;<br />
> 			&nbsp;#include &lt;CAENComm.h&gt; &nbsp;<br />
> 			&nbsp;}</p>
> 
> 			<p>With these changes everything seems to work fine.</p>
> 
> 			<p>However, I&#39;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 &nbsp;-fpermissive -
> I/home/pkunz/packages/midas/include -I. -I/home/pkunz/packages/midas/drivers/bus &nbsp; 
> /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()&#39;:<br />
> 			/home/pkunz/packages/midas/src/mfe.cxx:687: undefined reference to 
> `interrupt_configure(int, int, long)&#39;<br />
> 			/usr/bin/ld: /home/pkunz/packages/midas/lib/mfe.o: in function 
> `readout_enable(unsigned int)&#39;:<br />
> 			/home/pkunz/packages/midas/src/mfe.cxx:1236: undefined reference to 
> `interrupt_configure(int, int, long)&#39;<br />
> 			/usr/bin/ld: /home/pkunz/packages/midas/src/mfe.cxx:1238: undefined reference to 
> `interrupt_configure(int, int, long)&#39;<br />
> 			/usr/bin/ld: /home/pkunz/packages/midas/lib/mfe.o: in function `main&#39;:<br />
> 			/home/pkunz/packages/midas/src/mfe.cxx:2791: undefined reference to 
> `interrupt_configure(int, int, long)&#39;<br />
> 			/usr/bin/ld: /home/pkunz/packages/midas/src/mfe.cxx:2792: undefined reference to 
> `interrupt_configure(int, int, long)&#39;<br />
> 			collect2: error: ld returned 1 exit status<br />
> 			make: *** [Makefile:36: feMotor] Error 1</div>
> 
> 			<p>&nbsp;I guess the the aforementioned DAQ frontend compiles because its equipment 
> definitions don&#39;t call on the function `initialize_equipment()&#39;, but I can&#39;t figure out why 
> it doesn&#39;t work. Help is appreciated. P.K.</p>
> 			</td>
> 		</tr>
> 	</tbody>
> </table>
> 
> <p>&nbsp;</p>

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>&nbsp;</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: &nbsp; &nbsp; &nbsp;2.1<br />
> 			GIT revision: &nbsp; &nbsp; &nbsp; 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 &quot;ODB dump format&quot; to &quot;xml&quot;, events 
> 0x8000 and 0x8001 are included in the .mid file, however, the file last.xml is not created.
> </p>
> 
> 			<p>&nbsp;</p>
> 
> 			<p>&nbsp;</p>
> 
> 			<p>&nbsp;</p>
> 			</td>
> 		</tr>
> 	</tbody>
> </table>
> 
> <p>&nbsp;</p>

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>&nbsp;</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&#39;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: &lsquo;experimental&rsquo; in 
> namespace &lsquo;std&rsquo; does not name a type 32 | using basic_string_view = 
> ::std::experimental::basic_string_view&lt;_CharT,_Traits&gt;;</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>&nbsp;</p>

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]$

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.

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.

Goto page Previous 1, 2, 3 ... 56, 57, 58 ... 150, 151, 152 Next

ELOG V3.1.4-2e1708b5