| ID |
Date |
Author |
Topic |
Subject |
|
988
|
17 Mar 2014 |
Konstantin Olchanski | Info | ODB JSON support | > > > odbedit can now save ODB in JSON-formatted files.
> encode NaN, Inf and -Inf as JSON string values "NaN", "Infinity" and "-Infinity". (Corresponding to the respective Javascript values).
A new standard just came out - Oasis OData JSON format 4.0 -
http://docs.oasis-open.org/odata/odata-json-format/v4.0/os/odata-json-format-v4.0-os.html
Section 7.1 reads:
> Values of types [...] Edm.Single, Edm.Double, and Edm.Decimal are represented as JSON numbers, except for NaN, INF, and –INF which are represented as strings.
This is consistent with what we do in MIDAS - encode special numbers as strings. For now I think we stay with Javascript-standard "Infinity", "-Infinity",
but if more standards start using "INF", "-INF", maybe we will switch. It is easy enough to support both encodings in the JSON parser and in the ODB decoder.
https://xkcd.com/927/
K.O. |
|
2382
|
12 Apr 2022 |
Konstantin Olchanski | Info | ODB JSON support | > > > > odbedit can now save ODB in JSON-formatted files.
> > encode NaN, Inf and -Inf as JSON string values "NaN", "Infinity" and "-Infinity". (Corresponding to the respective Javascript values).
> http://docs.oasis-open.org/odata/odata-json-format/v4.0/os/odata-json-format-v4.0-os.html
> > Values of types [...] Edm.Single, Edm.Double, and Edm.Decimal are represented as JSON numbers,
> except for NaN, INF, and –INF which are represented as strings "NaN", "INF" and "-INF".
> https://xkcd.com/927/
Per xkcd, there is a new json standard "json5". In addition to other things, numeric
values NaN, +Infinity and -Infinity are encoded as literals NaN, Infinity and -Infinity (without quotes):
https://spec.json5.org/#numbers
Good discussion of this mess here:
https://stackoverflow.com/questions/1423081/json-left-out-infinity-and-nan-json-status-in-ecmascript
K.O. |
|
2383
|
13 Apr 2022 |
Stefan Ritt | Info | ODB JSON support | > Per xkcd, there is a new json standard "json5". In addition to other things, numeric
> values NaN, +Infinity and -Infinity are encoded as literals NaN, Infinity and -Infinity (without quotes):
> https://spec.json5.org/#numbers
Just for curiosity: Is this implemented by the midas json library now? |
|
2384
|
13 Apr 2022 |
Konstantin Olchanski | Info | ODB JSON support | > > Per xkcd, there is a new json standard "json5". In addition to other things, numeric
> > values NaN, +Infinity and -Infinity are encoded as literals NaN, Infinity and -Infinity (without quotes):
> > https://spec.json5.org/#numbers
>
> Just for curiosity: Is this implemented by the midas json library now?
MIDAS encodes NaN, Infinity and -Infinity as javascript compatible "NaN", "Infinity" and "-Infinity",
this encoding is popular with other projects and allows correct transmission of these values
from ODB to javascript. The test code for this is on the MIDAS "Example" page, scroll down
to "Test nan and inf encoding".
I think this type of encoding, using strings to encode special values, is more in the spirit of json,
compared to other approaches such as adding special literals just for a few special cases
leaving other special cases in the cold (ieee-754 specifies several different types of NaN,
you can encode them into different nan-strings, but not into the one nan-literal (need more nan-literals,
requires change to the standard and change to every json parser).
As editorial comment, it boggles my mind, what university or kindergarden these people went to
who made the biggest number, the smallest number and the imaginary number (sqrt(-1))
all equal to zero (all encoded as literal null).
K.O. |
|
866
|
08 Mar 2013 |
Konstantin Olchanski | Info | ODB /Experiment/MAX_EVENT_SIZE | Somebody pointed out an error in the MIDAS documentation regarding maximum event size
supported by MIDAS and the MAX_EVENT_SIZE #define in midas.h.
Since MIDAS svn rev 4801 (August 2010), one can create events with size bigger than
MAX_EVENT_SIZE in midas.h (without having to recompile MIDAS):
To do so, one must increase:
- the value of ODB /Experiment/MAX_EVENT_SIZE
- the size of the SYSTEM shared memory event buffer (and any buffers used by the event builder,
etc)
- max_event_size & co in your frontend.
Actual limits on the bank size and event size are written up here:
https://ladd00.triumf.ca/elog/Midas/757
The bottom line is that the maximum event size is limited by the size of the SYSTEM buffer which is
limited by the physical memory of your computer. No recompilation of MIDAS necessary.
K.O. |
|
1310
|
04 Aug 2017 |
Konstantin Olchanski | Info | Notes on installing midas from scratch | Notes on installing midas from scratch. The instruction on midaswiki will be synced with this later.
cd ~/packages
git clone ...
cd midas
make
cd ~
mkdir ~/online
cd ~/online
~/git/midas/darwin/bin/odbinit --env
source env.sh
~/git/midas/darwin/bin/odbinit --exptab
~/git/midas/darwin/bin/odbinit
ls -la
send:online olchansk$ ls -la
total 2376
drwxr-xr-x 15 olchansk staff 510 Aug 4 15:34 .
drwxr-xr-x+ 244 olchansk staff 8296 Aug 4 15:33 ..
-rw-r--r-- 1 olchansk staff 0 Aug 4 15:34 .ALARM.SHM
-rw-r--r-- 1 olchansk staff 0 Aug 4 15:34 .ELOG.SHM
-rw-r--r-- 1 olchansk staff 0 Aug 4 15:34 .HISTORY.SHM
-rw-r--r-- 1 olchansk staff 0 Aug 4 15:34 .MSG.SHM
-rw-r--r-- 1 olchansk staff 1183808 Aug 4 15:34 .ODB.SHM
-rw-r--r-- 1 olchansk staff 8 Aug 4 15:34 .ODB_SIZE.TXT
-rw-r--r-- 1 olchansk staff 15 Aug 4 15:34 .SHM_HOST.TXT
-rw-r--r-- 1 olchansk staff 12 Aug 4 15:34 .SHM_TYPE.TXT
-rw-r--r-- 1 olchansk staff 0 Aug 4 15:34 .SYSMSG.SHM
-rw-r--r-- 1 olchansk staff 341 Aug 4 15:33 env.csh
-rw-r--r-- 1 olchansk staff 322 Aug 4 15:33 env.sh
-rw-r--r-- 1 olchansk staff 40 Aug 4 15:34 exptab
-rw-r--r-- 1 olchansk staff 287 Aug 4 15:34 midas.log
send:online olchansk$
odbedit ### works
mhttpd ### bombs, requires SSL certificate https://bitbucket.org/tmidas/midas/issues/57/initial-mhttpd-should-bind-to-localhost
odbedit ### cd /experiment, set "http redirect to https" to no, set "midas https port" to 0
mhttpd ### runs now
connect to http://localhost:8080 ### status page works
restart mhttpd as mhttpd -D
mlogger -D
fetest ### runs, prints time and data
start a run from web page ### works
### fetest generates crazy data rate https://bitbucket.org/tmidas/midas/issues/58/fetest-crazy-data-rate
### go to history, define plot for SLOW/SLOW, see sine wave ### works
### history is written to expt dir, no good, go to "history"
### data files written to expt dir, no good, go to "data"
### midas.log written to data dir, no good (want expt dir)
### elog written to expt dir, go to "elog"
### logger channel config is wrong - gzip compression and crc32c should be enabled by default
### history config is wrong - FILE per-variable history should be enabled by default
K.O.
|
|
1311
|
07 Aug 2017 |
Stefan Ritt | Info | Notes on installing midas from scratch | Thanks for documenting this in detail. A few suggestions:
- is it really necessary to call odbedit three times? Maybe two or even three functions can be merged. Like you call odbinit, it checks if the environment is
there, and creates it automatically if not. Same with the exptab.
- can we make "http redirecto to https = n" and "midas https port = 0" as the default? Of course this has to go with binding to localhost only.
- does it make sense to define default directories for history, data files and midas.log? Maybe we could come with a "default scheme" which can then later
adjusted if needed.
- will you take care of the wrong logger channel config and history config?
Best regards,
Stefan
> Notes on installing midas from scratch. The instruction on midaswiki will be synced with this later.
>
> cd ~/packages
> git clone ...
> cd midas
> make
> cd ~
> mkdir ~/online
> cd ~/online
> ~/git/midas/darwin/bin/odbinit --env
> source env.sh
> ~/git/midas/darwin/bin/odbinit --exptab
> ~/git/midas/darwin/bin/odbinit
> ls -la
> send:online olchansk$ ls -la
> total 2376
> drwxr-xr-x 15 olchansk staff 510 Aug 4 15:34 .
> drwxr-xr-x+ 244 olchansk staff 8296 Aug 4 15:33 ..
> -rw-r--r-- 1 olchansk staff 0 Aug 4 15:34 .ALARM.SHM
> -rw-r--r-- 1 olchansk staff 0 Aug 4 15:34 .ELOG.SHM
> -rw-r--r-- 1 olchansk staff 0 Aug 4 15:34 .HISTORY.SHM
> -rw-r--r-- 1 olchansk staff 0 Aug 4 15:34 .MSG.SHM
> -rw-r--r-- 1 olchansk staff 1183808 Aug 4 15:34 .ODB.SHM
> -rw-r--r-- 1 olchansk staff 8 Aug 4 15:34 .ODB_SIZE.TXT
> -rw-r--r-- 1 olchansk staff 15 Aug 4 15:34 .SHM_HOST.TXT
> -rw-r--r-- 1 olchansk staff 12 Aug 4 15:34 .SHM_TYPE.TXT
> -rw-r--r-- 1 olchansk staff 0 Aug 4 15:34 .SYSMSG.SHM
> -rw-r--r-- 1 olchansk staff 341 Aug 4 15:33 env.csh
> -rw-r--r-- 1 olchansk staff 322 Aug 4 15:33 env.sh
> -rw-r--r-- 1 olchansk staff 40 Aug 4 15:34 exptab
> -rw-r--r-- 1 olchansk staff 287 Aug 4 15:34 midas.log
> send:online olchansk$
>
> odbedit ### works
> mhttpd ### bombs, requires SSL certificate https://bitbucket.org/tmidas/midas/issues/57/initial-mhttpd-should-bind-to-localhost
> odbedit ### cd /experiment, set "http redirect to https" to no, set "midas https port" to 0
> mhttpd ### runs now
> connect to http://localhost:8080 ### status page works
> restart mhttpd as mhttpd -D
> mlogger -D
> fetest ### runs, prints time and data
> start a run from web page ### works
> ### fetest generates crazy data rate https://bitbucket.org/tmidas/midas/issues/58/fetest-crazy-data-rate
> ### go to history, define plot for SLOW/SLOW, see sine wave ### works
> ### history is written to expt dir, no good, go to "history"
> ### data files written to expt dir, no good, go to "data"
> ### midas.log written to data dir, no good (want expt dir)
> ### elog written to expt dir, go to "elog"
> ### logger channel config is wrong - gzip compression and crc32c should be enabled by default
> ### history config is wrong - FILE per-variable history should be enabled by default
>
> K.O.
> |
|
745
|
16 Feb 2011 |
Konstantin Olchanski | Info | Notes on MIDAS history | Some notes on the MIDAS history.
MIDAS documentation at
http://midas.psi.ch/htmldoc/F_History_logging.html
describes:
- midas equipment concepts
- midas equipment event ids
- midas data banks
- midas history concepts
- history records (correspond to data banks)
- history record ids (correspond to equipment ids)
- history tags (describe the structure
- describes the code path from the user read function through odb to the mlogger to the history file
- midas history file internal data format
- documents the tool for looking inside history files - mhdump
But some things remain unclear after reading the documentation - where are the history definitions
saved? what happens if an equipment is deleted or renamed? what's all the mumbling about
/History/Events and /History/Tags? what's this /History/PerVariableHistory?
As I go through my review of the MIDAS history code, I will attempt to clarify some of this information.
1) PerVariableHistory.
The default value of 0 is intended to operate the midas history in "traditional" mode. In this mode:
- there is one history record for each equipment
- history record id is equal to the equipment id
- /History/Events and /History/Tags are not required and can be safely deleted
The downside of this history mode is that there is only one history record per equipment. If some
equipment has many banks not all of which are updated all at the same time, every time one bank is
updated, data for all banks is written to the history file, even if data in all those other banks had not
changed. The result is undesired duplication of data in midas history files. In turn, this leads to slow
down while making history plots (mhttpd has to read more data from bigger data files, which takes time)
and for long running experiments may pose problems with disk space for storing history files.
In addition, when logging history data into an SQL database, each history record is mapped into an SQL
table, so all variables from all banks of an equipment end up in the same SQL table - and in addition to
data duplication described above, a data presentation problem is created - database users and
administrators dislike having SQL tables with "too many" columns!
To solve both problems - reduce data duplication and avoid creating over-large SQL tables - per-
variable history has been implemented.
to be continued...
K.O. |
|
749
|
16 Feb 2011 |
Konstantin Olchanski | Info | Notes on MIDAS history | >
> 1) PerVariableHistory.
>
> The default value of 0 is intended to operate the midas history in "traditional" mode. In this mode:
> - there is one history record for each equipment
> - history record id is equal to the equipment id
> - /History/Events and /History/Tags are not required and can be safely deleted
>
I now commited an example experiment for testing and using non-per-variable history:
.../midas/examples/history1
I confirm that this example does work as expected after src/history_midas.cxx is updated to latest rev 4979 (today). I guess it also worked just
fine before breakage in svn rev 4827 last September.
svn rev 4980.
Here is the README file:
Example experiment "history1"
Purpose:
example and test of a simple periodic frontend writing slow controls data into midas history
To run:
use bash shell
assuming MIDAS is installed in $HOME/packages/midas on linux, otherwise edit setup.sh and Makefile
run make to build feslow.exe
run source ./setup.sh
when starting this experiment for the very first time, load experiment settings from odb.xml: odbedit -c "load odb.xml"
run ./start_daq.sh
mlogger and mhttpd should now be running
connect to the midas status page at http://localhost:8080 (port number is set in start_daq.sh
start the example frontend from the "programs" page
observe event number of equipment "slow" is incrementing
go to the "Slow" equipment page (click on "Slow" on the midas status page)
observe numbers are changing when you refresh the web page
from the midas status page, go to "history" -> "slow" - observe history plot for "SLOW[2]" shows a sine wave
from shell, examine contents of history file: "mhdump *.hst"
study feslow.cxx
Enjoy,
K.O. |
|
695
|
04 Mar 2010 |
Konstantin Olchanski | Info | Notes on MIDAS Alarm system | Notes on the implementation of the MIDAS alarm system.
Alarms are checked inside alarm.c::al_check(). This function is called by
cm_yield() every 10 seconds and by rpc_server_thread(), also every 10 seconds.
For remote midas clients, their al_check() issues an RPC_AL_CHECK RPC call into
the mserver, where rpc_server_dispatch() calls the local al_check().
As result, all alarm checks run inside a process directly attached to the local
midas shared memory (inside a local client or inside an mserver process for a
remote client).
Each and every midas client runs the alarm checks. To prevent race conditions
between different midas clients, access to al_check() is serialized using the
ALARM semaphore.
Inside al_check(), alarms are triggered using al_trigger_alarm(), which in turn
calls al_trigger_class(). Inside al_trigger_class(), the alarm is recorded into
an elog or into midas.log using cm_msg(MTALK).
Special note should be made of the ODB setting "/Alarm/Classes/xxx/System
message interval", which has a surprising effect - after an alarm is recorded
into system messages (using cm_msg(MTALK)), no record is made of any subsequent
alarms until the time interval set by this variable elapses. With default value
of 60 seconds, after one alarm, no more alarms are recorded for 60 seconds.
Also, because all the alarms are checked at the same time, only the first
triggered alarm will be recorded.
As of alarm.c rev 4683, "System message interval" set to 0 ensures that every
alarm is recorded into the midas log file. (In previous revisions, this setting
may still miss some alarms).
There are 3 types of alarms:
1) "program not running" alarms.
These alarms are enabled in ODB by setting "/Programs/ppp/Alarm class". Each
time al_check() runs, every program listed in "/Programs" is tested using
"cm_exist()" and if the program is not running, the time of first failure is
remembered in "/Programs/ppp/First failed".
If the program has not been running for longer than the time set in ODB
"/Programs/ppp/Check interval", an alarm is triggered (if enabled by
"/Programs/ppp/Alarm class" and the program is restarted (if enabled by
"/Programs/ppp/Auto restart").
The "not running" condition is tested every 10 seconds (each time al_check() is
called), but the frequency of "program not running" alarms can be reduced by
increasing the value of "/Alarms/Alarms/ppp/Check interval" (default value 60
seconds). This can be useful if "System message interval" is set to zero.
2) "evaluated" alarms
3) "periodic" alarms
There is nothing surprising in these alarms. Each alarm is checked with a time
period set by "/Alarm/xxx/Check interval". The value of an evaluated alarm is
computed using al_evaluate_condition().
K.O. |
|
160
|
13 Oct 2004 |
Konstantin Olchanski | Suggestion | No al_clear_alarm()? | We have al_trigger_alarm(), but no matching al_clear_alarm(), and I need it to
clear my alarm once the alarm condition no longer exists. Any objections if I
add this function? K.O. |
|
161
|
13 Oct 2004 |
Stefan Ritt | Suggestion | No al_clear_alarm()? | > We have al_trigger_alarm(), but no matching al_clear_alarm(), and I need it to
> clear my alarm once the alarm condition no longer exists. Any objections if I
> add this function? K.O.
The idea is that once an alarm got triggered, it stays until the user
acknowledged, even if the alarm condition has been disappeared. Through mhttpd,
the user can press the "Reset" button, which then executes al_reset_alarm().
However, it is possible to call al_reset_alarm() directly from user code to
achieve the same thing. |
|
162
|
13 Oct 2004 |
Konstantin Olchanski | Suggestion | No al_clear_alarm()? | > > We have al_trigger_alarm(), but no matching al_clear_alarm(), and I need it to
> > clear my alarm once the alarm condition no longer exists. Any objections if I
> > add this function? K.O.
>
> call al_reset_alarm()
Thanks. I must be quite blind as I did not see al_reset_alarm() in midas.h. I se eit
now. Thanks.
K.O. |
|
2824
|
04 Sep 2024 |
Stefan Ritt | Info | News MSCB++ API | I had two free afternoon and took the opportunity to write a new API for the MSCB
system. I'm not sure if anybody else actually uses MSCB (MIDAS slow control bus),
but anyhow.
The new API is contained in a single header file mscbxx.h, and it's extremely
simple to use. Here is some example code:
#include "mscbxx.h"
...
// connect to node 10 at submaster mscb123
midas::mscb m("mscb123", 10);
// print node info and all variables
std::cout << m << std::endl;
// refresh all variables (read from MSCB device)
m.read_range();
// access individual variables
float f = m[5]; // index access
f = m["In0"]; // name access
// write value to MSCB device
m["In0"] = 1.234;
...
Any feedback is welcome.
Stefan |
|
2830
|
11 Sep 2024 |
Konstantin Olchanski | Info | News MSCB++ API | > Here is some example code:
>
> #include "mscbxx.h"
> f = m["In0"]; // name access
> m["In0"] = 1.234;
> Any feedback is welcome.
Where is the example of error handling?
K.O. |
|
2857
|
24 Sep 2024 |
Stefan Ritt | Info | News MSCB++ API | > Where is the example of error handling?
#include "mscbxx.h"
#include "mexcept.h"
...
try {
// connect to node 10 at submaster mscb123
midas::mscb m("mscb123", 10);
// print a variable
std::cout << m["Input0"] << std::endl;
} catch (mexception e) {
std::cout << e << std::endl; // simply print exception
}
... |
|
1731
|
08 Nov 2019 |
Pierre Gorel | Bug Report | 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)) |
|
1732
|
12 Nov 2019 |
Konstantin Olchanski | Bug Report | 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))
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. |
|
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
|
|
1736
|
15 Nov 2019 |
Konstantin Olchanski | Bug Report | Newly installed MIDAS on OSX: mhttpd crahes | > It is reproducible alright.
Thanks. At first blush, a guess, read_passwords() is not thread-safe and is called from multiple threads, not protected by semaphore. Crash report shows 2 active threads
(one made it is far as processing the mjson rpc, the other one crashed in read_passwords()).
K.O.
> 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. |
|