| ID |
Date |
Author |
Topic |
Subject |
|
1081
|
29 Jul 2015 |
Javier Praena | Forum | error | Hello, I am new in the forum. We are running an experiment for a week with no
problems. Now we add a detector a we found an error. Even we come back to our
previous configuration the error continues appearing. Please, may someone help
us? You can find the error in the attachment. Thanks! |
| Attachment 1: sigsegv-error.jpg
|
|
|
1083
|
29 Jul 2015 |
Wes Gohn | Forum | error | SIGSEGV is a segmentation fault. Most often it means some ODB parameter is out of bounds or there is
an invalid memcpy somewhere in your code.
> Hello, I am new in the forum. We are running an experiment for a week with no
> problems. Now we add a detector a we found an error. Even we come back to our
> previous configuration the error continues appearing. Please, may someone help
> us? You can find the error in the attachment. Thanks! |
|
1084
|
29 Jul 2015 |
Konstantin Olchanski | Forum | error | > Hello, I am new in the forum. We are running an experiment for a week with no
> problems. Now we add a detector a we found an error. Even we come back to our
> previous configuration the error continues appearing. Please, may someone help
> us? You can find the error in the attachment. Thanks!
The error reported is SIGSEGV, which is a software fault (as opposed to a hardware fault like "printer is on fire" or "disk full").
Next step is to identify which program crashed and attach a debugger to the crashing executable or to the core dump.
You will use the debugger to generate the stack trace which will identify exactly the place where the program failed.
I recommend that one should always attach the stack trace to the problem reports on this forum. These stack traces are sometimes long and
scary and it is a bit of an art to read them, so do not worry if you do not understand what they say.
If you use "gdb", I recommend that you post your full debugger session:
bash> gdb myprogram
gdb> run my command line arguments
*crash*
gdb> where
... stack trace
gdb> quit
(If you use threads, please generate a stack trace for each thread)
If the crash location is inside midas code, congratulations, you may have found a bug in midas.
If the crash location is in your code, you have some debugging to do.
If you do not understand what I am talking about (gdb? core dump?), please read "unix/linux software development for dummies" book first.
K.O. |
|
2378
|
30 Mar 2022 |
Konstantin Olchanski | Bug Fix | erroneous removal of odb clients, fixed | commit https://bitbucket.org/tmidas/midas/commits/b1fe21445109774be3f059c2124727b414abf835
made on 2022-02-21 fixed a serious bug in ODB.
a multithread race condition against an incorrectly updated shared variable caused removal of
random clients from ODB with error message:
My client index %d in ODB is invalid: out of range 0..%d. Maybe this client was removed by a
timeout, see midas.log. Cannot continue, aborting...
the race is between db_open_database() in one program (executed when any midas program starts) and
db_get_my_client_locked() in all running midas programs.
as long as no midas programs are started (db_open_database() is not executed), this bug does not
happen.
if i.e. odbedit is executed very often, i.e. from a script, probability of hitting this bug becomes
quite high.
fixed now.
K.O. |
|
2606
|
19 Sep 2023 |
Frederik Wauters | Bug Report | epics fe "Start Command" | The epics frontend overwrites the "start command" odb after each start:
// set start command in ODB
midas::odb efe("/Programs/EPICS Frontend");
std::string p(__FILE__);
std::string s("build/epics_fe");
auto i = p.find("epics_fe.cxx");
p.replace(i, s.length(), s);
p = p.substr(0, i + s.length());
efe["Start command"].set_string_size(p, 256);
this should be set such that it only writes when the key is not there. It causes the following issue: on a pc with multiple experiments defined, you need to start the fe's with a "-e <name>" flag. |
|
2607
|
20 Sep 2023 |
Stefan Ritt | Bug Report | epics fe "Start Command" | Thanks for reporting this problem. It has been fixed today, so the start command is only written if it's emtpy.
Stefan |
|
1369
|
17 May 2018 |
Zaher Salman | Forum | embedding history in SVG | I am embedding histories into a custom page within an SVG,
<image x="21000" y="1000" width="6000" height="6000"
href="../HS/SampleCryo/SampleTemp.gif?width=230&scale=0.5h"/>
this works fine. However, I would like to update this regularly without
refreshing the full page via
<meta http-equiv="Refresh" content="60">
is there a good way to do that? By the way, the "Periodic update of parts of a
custom page" from the documentation does not seem to work here. |
|
2128
|
10 Mar 2021 |
Zaher Salman | Suggestion | embed modbvalue in SVG | Is it possible to embed modbvalue in an SVG for use within a custom page?
thanks. |
|
2129
|
10 Mar 2021 |
Stefan Ritt | Suggestion | embed modbvalue in SVG | You can't really embed it, but you can overlay it. You tag the SVG with a
"relative" position and then move the modbvalue with an "absolute" position over
it:
<svg style="position:relative" width="400" height="100">
<rect width="300" height="100" style="fill:rgb(255,0,0);stroke-width:3;stroke:rgb(0,0,0)" />
<div class="modbvalue" style="position:absolute;top:50px;left:50px" data-odb-path="/Runinfo/Run number"></div>
</svg> |
|
2156
|
26 Apr 2021 |
Zaher Salman | Suggestion | embed modbvalue in SVG | I found a way to embed modbvalue into a SVG:
<text x="100" y="100" font-size="30rem">
Run=<tspan class="modbvalue" data-odb-path="/Runinfo/Run number"></tspan>
</text>
This seems to behave better that the suggestion below.
> You can't really embed it, but you can overlay it. You tag the SVG with a
> "relative" position and then move the modbvalue with an "absolute" position over
> it:
>
> <svg style="position:relative" width="400" height="100">
> <rect width="300" height="100" style="fill:rgb(255,0,0);stroke-width:3;stroke:rgb(0,0,0)" />
> <div class="modbvalue" style="position:absolute;top:50px;left:50px" data-odb-path="/Runinfo/Run number"></div>
> </svg> |
|
1172
|
22 Mar 2016 |
Konstantin Olchanski | Info | emacs web-mode.el | For those who use emacs to edit web pages - the built-in CSS and Javascript modes seem to work
just fine for editing files.css and files.js, but the built-in html modes fall flat on modern web pages
which contain a mix of html, javascript inside <script> tags and javascript inside button "onclick"
attributes.
So I looked at several emacs "html5 modes" and web-mode.el works well for me - html is indented
correctly (default indent level is easy to change), javascript inside <script> tags is indented
correctly (default indent level is easy to change), javascript inside "onclick" attributes has to be
indented manually.
web-mode code repository and instructions are here, the author is very responsive and fixed my
one request (permit manual intentation of javascript inside html attributes):
https://github.com/fxbois/web-mode
I now edit the html files in the MIDAS repository using these emacs settings:
8s-macbook-pro:web-mode 8ss$ more ~/.emacs
(setq-default indent-tabs-mode nil)
(setq-default tab-width 3)
(add-to-list 'load-path "~/git/web-mode")
(require 'web-mode)
(add-to-list 'auto-mode-alist '("\\.html\\'" . web-mode))
(setq web-mode-markup-indent-offset 2)
(setq web-mode-css-indent-offset 2)
(setq web-mode-code-indent-offset 3)
(setq web-mode-script-padding 0)
(setq web-mode-attr-indent-offset 2)
8s-macbook-pro:web-mode 8ss$
K.O. |
|
64
|
30 Mar 2004 |
Konstantin Olchanski | | elog fixes | I am about to commit the mhttpd Elog fixes we have been using in TWIST since
about October. The infamous Elog "last N days" problem is fixed, sundry
memory overruns are caught and assert()ed.
For the curious, the "last N days" problem was caused by uninitialized data
in the elog handling code. A non-zero-terminated string was read from a file
and passed to atoi(). Here is a simplifed illustration:
char str[256]; // uninitialized, filled with whatever happens on the stack
read(file,str,6); // read 6 bytes, non-zero terminated
// str now looks like this: "123456UUUUUUUUU....", "U" is uninitialized memory
int len = atoi(str); // if the first "U" happens to be a number, we lose.
The obvious fix is to add "str[6]=0" before the atoi() call.
Attached is the CVS diff for the proposed changes. Please comment.
K.O. |
| Attachment 1: elog-fixes.txt
|
Index: src/midas.c
===================================================================
RCS file: /usr/local/cvsroot/midas/src/midas.c,v
retrieving revision 1.203
diff -u -r1.203 midas.c
--- src/midas.c 19 Mar 2004 09:58:22 -0000 1.203
+++ src/midas.c 31 Mar 2004 05:11:00 -0000
@@ -14814,8 +14814,9 @@
\********************************************************************/
/********************************************************************/
-void el_decode(char *message, char *key, char *result)
+void el_decode(char *message, char *key, char *result, int size)
{
+ char *rstart = result;
char *pc;
if (result == NULL)
@@ -14828,6 +14829,8 @@
*result++ = *pc++;
*result = 0;
}
+
+ assert(strlen(rstart) < size);
}
/**dox***************************************************************/
@@ -15020,9 +15023,9 @@
size = atoi(str + 9);
read(fh, message, size);
- el_decode(message, "Date: ", date);
- el_decode(message, "Thread: ", thread);
- el_decode(message, "Attachment: ", attachment);
+ el_decode(message, "Date: ", date, sizeof(date));
+ el_decode(message, "Thread: ", thread, sizeof(thread));
+ el_decode(message, "Attachment: ", attachment, sizeof(attachment));
/* buffer tail of logfile */
lseek(fh, 0, SEEK_END);
@@ -15092,7 +15095,7 @@
sprintf(message + strlen(message), "========================================\n");
strcat(message, text);
- assert(strlen(message) < sizeof(message)); // bomb out on array overrun.
+ assert(strlen(message) < sizeof(message)); /* bomb out on array overrun. */
size = 0;
sprintf(start_str, "$Start$: %6d\n", size);
@@ -15104,6 +15107,9 @@
sprintf(tag, "%02d%02d%02d.%d", tms->tm_year % 100, tms->tm_mon + 1,
tms->tm_mday, (int) TELL(fh));
+ /* size has to fit in 6 digits */
+ assert(size < 999999);
+
sprintf(start_str, "$Start$: %6d\n", size);
sprintf(end_str, "$End$: %6d\n\f", size);
@@ -15339,13 +15345,20 @@
return EL_FILE_ERROR;
}
- if (strncmp(str, "$End$: ", 7) == 0) {
- size = atoi(str + 7);
- lseek(*fh, -size, SEEK_CUR);
- } else {
+ if (strncmp(str, "$End$: ", 7) != 0) {
close(*fh);
return EL_FILE_ERROR;
}
+
+ /* make sure the input string to atoi() is zero-terminated:
+ * $End$: 355garbage
+ * 01234567890123456789 */
+ str[15] = 0;
+
+ size = atoi(str + 7);
+ assert(size > 15);
+
+ lseek(*fh, -size, SEEK_CUR);
/* adjust tag */
sprintf(strchr(tag, '.') + 1, "%d", (int) TELL(*fh));
@@ -15364,14 +15377,21 @@
}
lseek(*fh, -15, SEEK_CUR);
- if (strncmp(str, "$Start$: ", 9) == 0) {
- size = atoi(str + 9);
- lseek(*fh, size, SEEK_CUR);
- } else {
+ if (strncmp(str, "$Start$: ", 9) != 0) {
close(*fh);
return EL_FILE_ERROR;
}
+ /* make sure the input string to atoi() is zero-terminated
+ * $Start$: 606garbage
+ * 01234567890123456789 */
+ str[15] = 0;
+
+ size = atoi(str+9);
+ assert(size > 15);
+
+ lseek(*fh, size, SEEK_CUR);
+
/* if EOF, goto next day */
i = read(*fh, str, 15);
if (i < 15) {
@@ -15444,7 +15464,7 @@
\********************************************************************/
{
- int size, fh, offset, search_status;
+ int size, fh = 0, offset, search_status, rd;
char str[256], *p;
char message[10000], thread[256], attachment_all[256];
@@ -15462,10 +15482,24 @@
/* extract message size */
offset = TELL(fh);
- read(fh, str, 16);
- size = atoi(str + 9);
+ rd = read(fh, str, 15);
+ assert(rd == 15);
+
+ /* make sure the input string is zero-terminated before we call atoi() */
+ str[15] = 0;
+
+ /* get size */
+ size = atoi(str+9);
+
+ assert(strncmp(str,"$Start$:",8) == 0);
+ assert(size > 15);
+ assert(size < sizeof(message));
+
memset(message, 0, sizeof(message));
- read(fh, message, size);
+
+ rd = read(fh, message, size);
+ assert(rd > 0);
+ assert((rd+15 == size)||(rd == size));
close(fh);
@@ -15473,14 +15507,14 @@
if (strstr(message, "Run: ") && run)
*run = atoi(strstr(message, "Run: ") + 5);
- el_decode(message, "Date: ", date);
- el_decode(message, "Thread: ", thread);
- el_decode(message, "Author: ", author);
- el_decode(message, "Type: ", type);
- el_decode(message, "System: ", system);
- el_decode(message, "Subject: ", subject);
- el_decode(message, "Attachment: ", attachment_all);
- el_decode(message, "Encoding: ", encoding);
+ el_decode(message, "Date: ", date, 80); /* size from show_elog_submit_query() */
+ el_decode(message, "Thread: ", thread, sizeof(thread));
+ el_decode(message, "Author: ", author, 80); /* size from show_elog_submit_query() */
+ el_decode(message, "Type: ", type, 80); /* size from show_elog_submit_query() */
+ el_decode(message, "System: ", system, 80); /* size from show_elog_submit_query() */
+ el_decode(message, "Subject: ", subject, 256); /* size from show_elog_submit_query() */
+ el_decode(message, "Attachment: ", attachment_all, sizeof(attachment_all));
+ el_decode(message, "Encoding: ", encoding, 80); /* size from show_elog_submit_query() */
/* break apart attachements */
if (attachment1 && attachment2 && attachment3) {
@@ -15496,6 +15530,10 @@
strcpy(attachment3, p);
}
}
+
+ assert(strlen(attachment1) < 256); /* size from show_elog_submit_query() */
+ assert(strlen(attachment2) < 256); /* size from show_elog_submit_query() */
+ assert(strlen(attachment3) < 256); /* size from show_elog_submit_query() */
}
/* conver thread in reply-to and reply-from */
|
|
65
|
30 Mar 2004 |
Stefan Ritt | | elog fixes | Thanks for fixing these long lasting bugs. The code is much cleaner now, please
commit it. |
|
2671
|
15 Jan 2024 |
Frederik Wauters | Forum | dump history FILE files | We switched from the history files from MIDAS to FILE, so we have *.dat files now (per variable), instead of the old *.hst.
How shoul
d one now extract data from these data files? With the old *,hst files I can e.g. mhdump -E 102 231010.hst
but with the new *.dat files I get
...2023/history$ mhdump -E 0 -T "Run number" mhf_1697445335_20231016_run_transitions.dat | head -n 15
event name: [Run transitions], time [1697445335]
tag: tag: /DWORD 1 4 /timestamp
tag: tag: UINT32 1 4 State
tag: tag: UINT32 1 4 Run number
record size: 12, data offset: 1024
record 0, time 1697557722, incr 112387
record 1, time 1697557783, incr 61
record 2, time 1697557804, incr 21
record 3, time 1697557834, incr 30
record 4, time 1697557888, incr 54
record 5, time 1697558318, incr 430
record 6, time 1697558323, incr 5
record 7, time 1697558659, incr 336
record 8, time 1697558668, incr 9
record 9, time 1697558753, incr 85
not very intelligible
Yes, I can do csv export on the webpage. But it would be nice to be able to extract from just the files. Also, the webpage export only saves the data shown ( range limited and/or downsampled) |
|
2691
|
28 Jan 2024 |
Konstantin Olchanski | Forum | dump history FILE files | $ cat mhf_1697445335_20231016_run_transitions.dat
event name: [Run transitions], time [1697445335]
tag: tag: /DWORD 1 4 /timestamp
tag: tag: UINT32 1 4 State
tag: tag: UINT32 1 4 Run number
record size: 12, data offset: 1024
...
data is in fixed-length record format. from the file header, you read "record size" is 12 and data starts at offset 1024.
the 12 bytes of the data record are described by the tags:
4 bytes of timestamp (DWORD, unix time)
4 bytes of State (UINT32)
4 bytes of "Run number" (UINT32)
endianess is "local endian", which means "little endian" as we have no big-endian hardware anymore to test endian conversions.
file format is designed for reading using read() or mmap().
and you are right mhdump, does not work on these files, I guess I can write another utility that does what I just described and spews the numbers to stdout.
K.O. |
|
2716
|
18 Feb 2024 |
Frederik Wauters | Forum | dump history FILE files | > $ cat mhf_1697445335_20231016_run_transitions.dat
> event name: [Run transitions], time [1697445335]
> tag: tag: /DWORD 1 4 /timestamp
> tag: tag: UINT32 1 4 State
> tag: tag: UINT32 1 4 Run number
> record size: 12, data offset: 1024
> ...
>
> data is in fixed-length record format. from the file header, you read "record size" is 12 and data starts at offset 1024.
>
> the 12 bytes of the data record are described by the tags:
> 4 bytes of timestamp (DWORD, unix time)
> 4 bytes of State (UINT32)
> 4 bytes of "Run number" (UINT32)
>
> endianess is "local endian", which means "little endian" as we have no big-endian hardware anymore to test endian conversions.
>
> file format is designed for reading using read() or mmap().
>
> and you are right mhdump, does not work on these files, I guess I can write another utility that does what I just described and spews the numbers to stdout.
>
> K.O.
Thanks for the answer. As this FILE system is advertised as the new default (eog:2617), this format does merit some more WIKI info. |
|
1141
|
20 Nov 2015 |
Konstantin Olchanski | Info | documented, merged: midas JSON-RPC interface | > The JSON RPC branch has been merged into main MIDAS.
The interface is now mostly documented, go here: https://midas.triumf.ca/MidasWiki/index.php/Mjsonrpc
Documentation for individual javascript functions in mhttpd.js not merged into the MIDAS documentation yet, because the API is being converted to the Javascript Promise
pattern (git branch feature/js_promise).
The functions available from mhttpd.js are documented via doxygen, also linked from the mjsonrpc wiki page.
K.O. |
|
2719
|
27 Feb 2024 |
Pavel Murat | Forum | displaying integers in hex format ? | Dear MIDAS Experts,
I'm having an odd problem when trying to display an integer stored in ODB on a custom
web page: the hex specifier, "%x", displays integers as if it were "%d" .
- attachment 1 shows the layout and the contents of the ODB sub-tree in question
- attachment 2 shows the web page as it is displayed
- attachment 3 shows the snippet of html/js producing the web page
I bet I'm missing smth trivial - an advice is greatly appreciated!
Also, is there an equivalent of a "0x%04x" specifier to have the output formatted
into a fixed length string ?
-- thanks, regards, Pasha |
| Attachment 1: 2024_02_27_dtc_registers_in_odb.png
|
|
| Attachment 2: 2024_02_27_custom_page.png
|
|
| Attachment 3: 2024_02_27_custom_page_html.png
|
|
|
2720
|
27 Feb 2024 |
Stefan Ritt | Forum | displaying integers in hex format ? | Thanks for reporting that bug. I fixed it and committed the change to the develop branch.
Stefan |
|
2721
|
27 Feb 2024 |
Pavel Murat | Forum | displaying integers in hex format ? | Hi Stefan (and Ben),
thanks for reacting so promptly - your commits on Bitbucket fixed the problem.
For those of us who knows little about how the web browsers work:
- picking up the fix required flushing the cache of the MIDAS client web browser - apparently the web browser
I'm using - Firefox 115.6 - cached the old version of midas.js but wouldn't report it cached and wouldn't load
the updated file on its own.
-- thanks again, regards, Pasha |
|