| ID |
Date |
Author |
Topic |
Subject |
|
2850
|
16 Sep 2024 |
Mark Grimes | Bug Report | Crash using ODB watch | Hi,
Maybe I've misunderstood the code, but odb::watch() creates a deep copy of itself to set the watch to. The comment where this happens specifies that this is in case the current one goes out of scope. See https://bitbucket.org/tmidas/midas/src/2878647fb73648474b35223ce53a125180f751b3/src/odbxx.cxx#lines-1393:1395
So as far as I can tell allowing the current odb instance to go out of scope is supported.
Thanks,
Mark.
> Okay, but this is then a big issue IMO. For Mu3e we do this in every frontend and I also checked again all of these watches are broken at the moment (with commit 3ad98c5 they worked).
>
> In the old style we did for example (see https://bitbucket.org/tmidas/midas/src/develop/examples/crfe/crfe.cxx):
>
> INT frontend_init()
> {
> HNDLE hKey;
>
> // create Settings structure in ODB
> db_create_record(hDB, 0, "Equipment/Clock Reset/Settings", strcomb1(cr_settings_str).c_str());
> db_find_key(hDB, 0, "/Equipment/Clock Reset", &hKey);
> assert(hKey);
>
> db_watch(hDB, hKey, cr_settings_changed, NULL);
>
> /*
> * Set our transition sequence. The default is 500. Setting it
> * to 600 means we are called AFTER most other clients.
> */
> cm_set_transition_sequence(TR_START, 600);
>
> return CM_SUCCESS;
> }
>
> I thought this will be the same (under the hood) in the current odbxx way via:
>
> odb settings("Equipment/Clock Reset/Settings");
> settings.watch(cr_settings_changed);
>
> Best,
> Marius
>
>
> > Well, the object *went* out of scope. For my code it‘s hard to realize this, so the error reporting is poor. Also the first object should have the same
> > problem. Just by accident that it does not crash.
> >
> > Stefan
> >
> > > This is not the case here. Note that the error message: "Callback received for a midas::odb object which went out of scope" is not called! The segmentation fault happens later line 96.
> > >
> > > > The answer is in the error message: „Object went out of scope“. When your frontent_init() exits, the odb objects are destroyed. When you get a callback, it‘s linked to the
> > > > destroyed object. This is like if you have a local string and pass a reference to that string in the return of the function.
> > > >
> > > > Use a global object (bad) or use „new“ (potential memory leak). I would use a global structure which holds all odb objects.
> > > >
> > > > Stefan
> > > >
> > > > >
> > > > > last week I was running MIDAS with the commit 3ad98c5. Today I updated MIDAS and now all my watch functions are crashing. Attached I have a minimal example frontend of the problem.
> > > > >
> > > > > In our software we have two functions one which sets up the ODB values of the frontend and another one which sets up all watch functions. So overall we connect two time to the ODB during fronend_init one time to create the values and one time to create the watch. In the example code a simple version of this setup is shown:
> > > > >
> > > > > INT frontend_init() {
> > > > >
> > > > > cm_msg(MINFO, "frontend_init() setup", "Test FE");
> > > > >
> > > > > odb settings = {
> > > > > {"Test", 123},
> > > > > {"sub", {}}
> > > > > };
> > > > > settings.connect_and_fix_structure("/Equipment/Test FE/Settings");
> > > > > // settings.watch(watch); <-- this works without segmentation fault
> > > > >
> > > > > odb new_settings("/Equipment/Test FE/Settings");
> > > > > new_settings.watch(watch); // <-- here I am getting a segmentation fault
> > > > >
> > > > > return CM_SUCCESS;
> > > > > }
> > > > >
> > > > > When I directly set the watch everything runs fine however, when I create a new ODB object and use this one to set a watch I am getting the following segmentation fault:
> > > > >
> > > > > Process 18474 stopped
> > > > > * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x34)
> > > > > frame #0: 0x000000010004fa38 test_fe`midas::odb::watch_callback(hDB=<unavailable>, hKey=<unavailable>, index=0, info=0x00006000002001c0) at odbxx.cxx:96:25 [opt]
> > > > > 93 if (po->m_data == nullptr)
> > > > > 94 mthrow("Callback received for a midas::odb object which went out of scope");
> > > > > 95 midas::odb *poh = search_hkey(po, hKey);
> > > > > -> 96 poh->m_last_index = index;
> > > > > 97 po->m_watch_callback(*poh);
> > > > > 98 poh->m_last_index = -1;
> > > > > 99 }
> > > > >
> > > > > Best,
> > > > > Marius |
|
2851
|
17 Sep 2024 |
Konstantin Olchanski | Bug Report | Crash using ODB watch | > {
> odb new_settings("/Equipment/Test FE/Settings");
> new_settings.watch(watch); // <-- here I am getting a segmentation fault
> }
this code has a bug. "watch" is attached to object "new_settings" that is deleted
after the closing curly bracket.
I would say Stefan's odb API should not allow you to write code like this. an API defect.
K.O. |
|
2852
|
18 Sep 2024 |
Marius Koeppel | Bug Report | Crash using ODB watch | I created a PR to fix this issue https://bitbucket.org/tmidas/midas/pull-requests/42.
The crash happened since the change in commit 3ad98c5 always got the ODB via XML.
However, the creation from XML should only be used when a user wants to read fast (and when we are on a remote machine) so I added the flag use_from_xml to explicitly specify this.
> > {
> > odb new_settings("/Equipment/Test FE/Settings");
> > new_settings.watch(watch); // <-- here I am getting a segmentation fault
> > }
>
> this code has a bug. "watch" is attached to object "new_settings" that is deleted
> after the closing curly bracket.
> I would say Stefan's odb API should not allow you to write code like this. an API defect.
As pointed out in the thread this feature is explicitly supported by odbxx.cxx:
void odb::watch(std::function<void(midas::odb &)> f) {
if (m_hKey == 0 || m_hKey == -1)
mthrow("watch() called for ODB key \"" + m_name +
"\" which is not connected to ODB");
// create a deep copy of current object in case it
// goes out of scope
midas::odb* ow = new midas::odb(*this);
ow->m_watch_callback = f;
db_watch(s_hDB, m_hKey, midas::odb::watch_callback, ow);
// put object into watchlist
g_watchlist.push_back(ow);
}
Also in the old way (see for example https://bitbucket.org/tmidas/midas/src/191d13f98626fae533cbca17b00df7ee361edf16/examples/crfe/crfe.cxx#lines-126) it was possible to create a watch in a scope without the user taking care that the "object" does not go out of scope.
I think this feature should be supported by the framework.
Best,
Marius |
|
2853
|
20 Sep 2024 |
Stefan Ritt | Bug Report | Crash using ODB watch | The problem has been fixed in the current version. Here is my analysis:
- the midas::odb object *can* go out of scope in the function, since the odb::watch() function creates a deep copy of the object.
This does not cause a memory leak if one call odb::unwatch_all() at the end of a program.
- The creation from XML had a flaw where the ODB key handle ("hKey") is not initialized since it is not passed by the db_copy_xml() function.
I added code to db_copy_xml() to also fetch the key handle in the XML file, which now fixes the issue. Please note that you have to
update both the server and client side of midas to get this functionality if you are using it by a remote client.
- I saw the flag MK added on his pull request to the constructor of odb::odb(). This is a way to fight the symptoms (by creating an
object the "old" way if not otherwise needed, but how we have the cause cured. Nevertheless I added that parameter, but set to to true by default:
odb::odb(const std::string &str, bool init_via_xml = true);
since this should be fully working now and should always be faster than the old method. I only keep it for debugging should we observe
another flaw in odb_from_xml().
Best regards,
Stefan |
|
819
|
04 Jul 2012 |
Konstantin Olchanski | Bug Report | Crash after recursive use of rpc_execute() | I am looking at a MIDAS kaboom when running out of space on the data disk - everything was freezing
up, even the VME frontend crashed sometimes.
The freeze was traced to ROOT use in mlogger - it turns out that ROOT intercepts many signal handlers,
including SIGSEGV - but instead of crashing the program as God intended, ROOT SEGV handler just hangs,
and the rest of MIDAS hangs with it. One solution is to always build mlogger without ROOT support -
does anybody use this feature anymore? Or reset the signal handlers back to the default setting somehow.
Freeze fixed, now I see a crash (seg fault) inside mlogger, in the newly introduced memmove() function
inside the MIDAS RPC code rpc_execute(). memmove() replaced memcpy() in the same place and I am
surprised we did not see this crash with memcpy().
The crash is caused by crazy arguments passed to memmove() - looks like corrupted RPC arguments
data.
Then I realized that I see a recursive call to rpc_execute(): rpc_execute() calls tr_stop() calls cm_yield() calls
ss_suspend() calls rpc_execute(). The second rpc_execute successfully completes, but leave corrupted
data for the original rpc_execute(), which happily crashes. At the moment of the crash, recursive call to
rpc_execute() is no longer visible.
Note that rpc_execute() cannot be called recursively - it is not re-entrant as it uses a global buffer for RPC
argument processing. (global tls_buffer structure).
Here is the mlogger stack trace:
#0 0x00000032a8032885 in raise () from /lib64/libc.so.6
#1 0x00000032a8034065 in abort () from /lib64/libc.so.6
#2 0x00000032a802b9fe in __assert_fail_base () from /lib64/libc.so.6
#3 0x00000032a802bac0 in __assert_fail () from /lib64/libc.so.6
#4 0x000000000041d3e6 in rpc_execute (sock=14, buffer=0x7ffff73fc010 "\340.", convert_flags=0) at
src/midas.c:11478
#5 0x0000000000429e41 in rpc_server_receive (idx=1, sock=<value optimized out>, check=<value
optimized out>) at src/midas.c:12955
#6 0x0000000000433fcd in ss_suspend (millisec=0, msg=0) at src/system.c:3927
#7 0x0000000000429b12 in cm_yield (millisec=100) at src/midas.c:4268
#8 0x00000000004137c0 in close_channels (run_number=118, p_tape_flag=0x7fffffffcd34) at
src/mlogger.cxx:3705
#9 0x000000000041390e in tr_stop (run_number=118, error=<value optimized out>) at
src/mlogger.cxx:4148
#10 0x000000000041cd42 in rpc_execute (sock=12, buffer=0x7ffff73fc010 "\340.", convert_flags=0) at
src/midas.c:11626
#11 0x0000000000429e41 in rpc_server_receive (idx=0, sock=<value optimized out>, check=<value
optimized out>) at src/midas.c:12955
#12 0x0000000000433fcd in ss_suspend (millisec=0, msg=0) at src/system.c:3927
#13 0x0000000000429b12 in cm_yield (millisec=1000) at src/midas.c:4268
#14 0x0000000000416c50 in main (argc=<value optimized out>, argv=<value optimized out>) at
src/mlogger.cxx:4431
K.O. |
|
820
|
04 Jul 2012 |
Konstantin Olchanski | Bug Report | Crash after recursive use of rpc_execute() | > ... I see a recursive call to rpc_execute(): rpc_execute() calls tr_stop() calls cm_yield() calls
> ss_suspend() calls rpc_execute()
> ... rpc_execute() cannot be called recursively - it is not re-entrant as it uses a global buffer
It turns out that rpc_server_receive() also need protection against recursive calls - it also uses
a global buffer to receive network data.
My solution is to protect rpc_server_receive() against recursive calls by detecting recursion and returning SS_SUCCESS (to ss_suspend()).
I was worried that this would cause a tight loop inside ss_suspend() but in practice, it looks like ss_suspend() tries to call
us about once per second. I am happy with this solution. Here is the diff:
@@ -12813,7 +12815,7 @@
/********************************************************************/
-INT rpc_server_receive(INT idx, int sock, BOOL check)
+INT rpc_server_receive1(INT idx, int sock, BOOL check)
/********************************************************************\
Routine: rpc_server_receive
@@ -13047,7 +13049,28 @@
return status;
}
+/********************************************************************/
+INT rpc_server_receive(INT idx, int sock, BOOL check)
+{
+ static int level = 0;
+ int status;
+ // Provide protection against recursive calls to rpc_server_receive() and rpc_execute()
+ // via rpc_execute() calls tr_stop() calls cm_yield() calls ss_suspend() calls rpc_execute()
+
+ if (level != 0) {
+ //printf("*** enter rpc_server_receive level %d, idx %d sock %d %d -- protection against recursive use!\n", level, idx, sock, check);
+ return SS_SUCCESS;
+ }
+
+ level++;
+ //printf(">>> enter rpc_server_receive level %d, idx %d sock %d %d\n", level, idx, sock, check);
+ status = rpc_server_receive1(idx, sock, check);
+ //printf("<<< exit rpc_server_receive level %d, idx %d sock %d %d, status %d\n", level, idx, sock, check, status);
+ level--;
+ return status;
+}
+
/********************************************************************/
INT rpc_server_shutdown(void)
/********************************************************************\
ladd02:trinat~/packages/midas>svn info src/midas.c
Path: src/midas.c
Name: midas.c
URL: svn+ssh://svn@savannah.psi.ch/repos/meg/midas/trunk/src/midas.c
Repository Root: svn+ssh://svn@savannah.psi.ch/repos/meg/midas
Repository UUID: 050218f5-8902-0410-8d0e-8a15d521e4f2
Revision: 5297
Node Kind: file
Schedule: normal
Last Changed Author: olchanski
Last Changed Rev: 5294
Last Changed Date: 2012-06-15 10:45:35 -0700 (Fri, 15 Jun 2012)
Text Last Updated: 2012-06-29 17:05:14 -0700 (Fri, 29 Jun 2012)
Checksum: 8d7907bd60723e401a3fceba7cd2ba29
K.O. |
|
821
|
13 Jul 2012 |
Stefan Ritt | Bug Report | Crash after recursive use of rpc_execute() | > Then I realized that I see a recursive call to rpc_execute(): rpc_execute() calls tr_stop() calls cm_yield() calls
> ss_suspend() calls rpc_execute(). The second rpc_execute successfully completes, but leave corrupted
> data for the original rpc_execute(), which happily crashes. At the moment of the crash, recursive call to
> rpc_execute() is no longer visible.
This is really strange. I did not protect rpc_execute against recursive calls since this should not happen. rpc_server_receive() is linked to rpc_call() on the client side. So there cannot be
several rpc_call() since there I do the recursive checking (also multi-thread checking) via a mutex. See line 10142 in midas.c. So there CANNOT be recursive calls to rpc_execute() because
there cannot be recursive calls to rpc_server_receive(). But apparently there are, according to your stack trace.
So even if your patch works fine, I would like to know where the recursive calls to rpc_server_receive() come from. Since we have one subproces of mserver for each client, there should only
be one client connected to each mserver process, and the client is protected via the mutex in rpc_call(). Can you please debug this? I would like to understand what is going on there. Maybe
there is a deeper underlying problem, which we better solve, otherwise it might fall back on use in the future.
For debugging, you have to see what commands rpc_call() send and what rpc_server_receive() gets, maybe by writing this into a common file together with a time stamp.
SR |
|
618
|
18 Aug 2009 |
Denis Calvet | Suggestion | Could not create strings other than 32 characters with odbedit -c "..." command | Hi,
I am writing shell scripts to create some tree structure in an ODB. When
creating an array of strings, the default length of each string element is 32
characters. If odbedit is used interactively to create the array of strings,
the user is prompted to enter a different length if desired. But if the
command odbedit is called from a shell script, I did not succeed in passing
the argument to get a different length.
I tried:
odbedit -c "create STRING Test[8][40]"
Or:
odbedit -c "create STRING Test[8] 40"
Or:
odbedit -c "create STRING Test[8] \n 40"
etc. all produce an array of 8 strings with 32 characters each.
I haven't tried all possible syntaxes, but I suspect the length argument is
dropped. If it has not been fixed in a later release than the one I am using,
could this problem be looked at?
Thanks,
Denis.
|
|
627
|
03 Sep 2009 |
Stefan Ritt | Suggestion | Could not create strings other than 32 characters with odbedit -c "..." command | > Hi,
> I am writing shell scripts to create some tree structure in an ODB. When
> creating an array of strings, the default length of each string element is 32
> characters. If odbedit is used interactively to create the array of strings,
> the user is prompted to enter a different length if desired. But if the
> command odbedit is called from a shell script, I did not succeed in passing
> the argument to get a different length.
> I tried:
> odbedit -c "create STRING Test[8][40]"
> Or:
> odbedit -c "create STRING Test[8] 40"
> Or:
> odbedit -c "create STRING Test[8] \n 40"
> etc. all produce an array of 8 strings with 32 characters each.
> I haven't tried all possible syntaxes, but I suspect the length argument is
> dropped. If it has not been fixed in a later release than the one I am using,
> could this problem be looked at?
Ok, I added a command
odbedit -c "create STRING Test[8][40]"
which works now. Please update to SVN revision 4555 of odbedit.c
- Stefan |
|
634
|
06 Sep 2009 |
Exaos Lee | Suggestion | Could not create strings other than 32 characters with odbedit -c "..." command | > Ok, I added a command
>
> odbedit -c "create STRING Test[8][40]"
>
> which works now. Please update to SVN revision 4555 of odbedit.c
>
> - Stefan
If I want to create only one string, should I write like this:
odbedit -c "create STRING Test[] [256]"
OK. I need it. I will try the new odbedit. |
|
640
|
06 Sep 2009 |
Exaos Lee | Suggestion | Could not create strings other than 32 characters with odbedit -c "..." command | > > Ok, I added a command
> >
> > odbedit -c "create STRING Test[8][40]"
> >
> > which works now. Please update to SVN revision 4555 of odbedit.c
> >
> > - Stefan
>
> If I want to create only one string, should I write like this:
>
> odbedit -c "create STRING Test[] [256]"
>
> OK. I need it. I will try the new odbedit.
"create STRING test[1][256]" works. |
|
208
|
21 Apr 2005 |
Konstantin Olchanski | Suggestion | Correct MIDASSYS setting? | Current MIDAS versions nag me about setting the env.variable MIDASSYS to the
"midas installation directory", but I do not have one, so what should I set
MIDASSYS to? I checkout MIDAS from cvs into /home/olchansk/daq/midas, build it
there, run it from there. I never do "make install" (I am not "root" on every
machine; I am not the only MIDAS user on every machine). What should I set
MIDASSYS to? K.O. |
|
209
|
22 Apr 2005 |
Stefan Ritt | Suggestion | Correct MIDASSYS setting? | > Current MIDAS versions nag me about setting the env.variable MIDASSYS to the
> "midas installation directory", but I do not have one, so what should I set
> MIDASSYS to? I checkout MIDAS from cvs into /home/olchansk/daq/midas, build it
> there, run it from there. I never do "make install" (I am not "root" on every
> machine; I am not the only MIDAS user on every machine). What should I set
> MIDASSYS to? K.O.
Then set it to /home/olchansk/daq/midas. The reason for MIDASSYS is the same as
for ROOTSYS. Having it allows other packages like ROME to access the Midas source
code, include files and libraries. |
|
1905
|
07 May 2020 |
Estelle | Bug Report | Conflic between Rootana and midas about the redefinition of TID_xxx data types | Dear Midas and Rootana people,
We have tried to update our midas DAQ with the new TID definitions describe in https://midas.triumf.ca/elog/Midas/1871
And we have noticed an incompatibility of this new definitions with Rootana when reading an XmlOdb in our offline analyzer.
The problem comes from the function FindArrayPath in XmlOdb.cxx and the comparison of bank type as strings.
Ex: comparing the strings "DWORD" and "UNINT32"
An naive solution would be to print the number associated to the type (ex: '6' for DWORD/UNINT32), but that would mean changing Rootana and Midas source code. Moreover, it does decrease the readability of the XmlOdb file.
Thanks for your time.
Estelle |
|
1911
|
20 May 2020 |
Konstantin Olchanski | Bug Report | Conflic between Rootana and midas about the redefinition of TID_xxx data types | > Dear Midas and Rootana people,
>
> We have tried to update our midas DAQ with the new TID definitions describe in https://midas.triumf.ca/elog/Midas/1871
>
> And we have noticed an incompatibility of this new definitions with Rootana when reading an XmlOdb in our offline analyzer.
>
> The problem comes from the function FindArrayPath in XmlOdb.cxx and the comparison of bank type as strings.
> Ex: comparing the strings "DWORD" and "UNINT32"
>
> An naive solution would be to print the number associated to the type (ex: '6' for DWORD/UNINT32), but that would mean changing Rootana and Midas source code. Moreover, it does decrease the readability of the XmlOdb file.
>
Hi, it is unfortunate that a change was made in MIDAS that is incompatible with existing analysis software. I shall update the ROOTANA package to deal with this ASAP.
K.O. |
|
854
|
24 Jan 2013 |
Konstantin Olchanski | Info | Compression benchmarks | In the DEAP experiment, the normal MIDAS mlogger gzip compression is not fast enough for some data
taking modes, so I am doing tests of other compression programs. Here is the results.
Executive summary:
fastest compression is no compression (cat at 1800 Mbytes/sec - memcpy speed), next best are:
"lzf" at 300 Mbytes/sec and "lzop" at 250 Mbytes/sec with 50% compression
"gzip -1" at around 70 Mbytes/sec with around 70% compression
"bzip2" at around 12 Mbytes/sec with around 80% compression
"pbzip2", as advertised, scales bzip2 compression linearly with the number of CPUs to 46 Mbytes/sec (4
real CPUs), then slower to a maximum 60 Mbytes/sec (8 hyper-threaded CPUs).
This confirms that our original choice of "gzip -1" method for compression using zlib inside mlogger is
still a good choice. bzip2 can gain an additional 10% compression at the cost of 6 times more CPU
utilization. lzo/lzf can do 50% compression at GigE network speed and at "normal" disk speed.
I think these numbers make a good case for adding lzo/lzf compression to mlogger.
Comments about the data:
- time measured is the "elapsed" time of the compression program. it excludes the time spent flushing
the compressed output file to disk.
- the relevant number is the first rate number (input data rate)
- test machine has 32GB of RAM, so all I/O is cached, disk speed does not affect these results
- "cat" gives a measure of overall machine "speed" (but test file is too small to give precise measurement)
- "gzip -1" is the recommended MIDAS mlogger compression setting
- "pbzip2 -p8" uses 8 "hyper-threaded" CPUs, but machine only has 4 "real" CPU cores
<pre>
cat : time 0.2s, size 431379371 431379371, comp 0%, rate 1797M/s 1797M/s
cat : time 0.6s, size 1013573981 1013573981, comp 0%, rate 1809M/s 1809M/s
cat : time 1.1s, size 2027241617 2027241617, comp 0%, rate 1826M/s 1826M/s
gzip -1 : time 6.4s, size 431379371 141008293, comp 67%, rate 67M/s 22M/s
gzip : time 30.3s, size 431379371 131017324, comp 70%, rate 14M/s 4M/s
gzip -9 : time 94.2s, size 431379371 133071189, comp 69%, rate 4M/s 1M/s
gzip -1 : time 15.2s, size 1013573981 347820209, comp 66%, rate 66M/s 22M/s
gzip -1 : time 29.4s, size 2027241617 638495283, comp 69%, rate 68M/s 21M/s
bzip2 -1 : time 34.4s, size 431379371 91905771, comp 79%, rate 12M/s 2M/s
bzip2 : time 33.9s, size 431379371 86144682, comp 80%, rate 12M/s 2M/s
bzip2 -9 : time 34.2s, size 431379371 86144682, comp 80%, rate 12M/s 2M/s
pbzip2 -p1 : time 34.9s, size 431379371 86152857, comp 80%, rate 12M/s 2M/s (1 CPU)
pbzip2 -p1 -1 : time 34.6s, size 431379371 91935441, comp 79%, rate 12M/s 2M/s
pbzip2 -p1 -9 : time 34.8s, size 431379371 86152857, comp 80%, rate 12M/s 2M/s
pbzip2 -p2 : time 17.6s, size 431379371 86152857, comp 80%, rate 24M/s 4M/s (2 CPU)
pbzip2 -p3 : time 11.9s, size 431379371 86152857, comp 80%, rate 36M/s 7M/s (3 CPU)
pbzip2 -p4 : time 9.3s, size 431379371 86152857, comp 80%, rate 46M/s 9M/s (4 CPU)
pbzip2 -p4 : time 45.3s, size 2027241617 384406870, comp 81%, rate 44M/s 8M/s
pbzip2 -p8 : time 33.3s, size 2027241617 384406870, comp 81%, rate 60M/s 11M/s
lzop -1 : time 1.6s, size 431379371 213416336, comp 51%, rate 261M/s 129M/s
lzop : time 1.7s, size 431379371 213328371, comp 51%, rate 249M/s 123M/s
lzop : time 4.3s, size 1013573981 515317099, comp 49%, rate 234M/s 119M/s
lzop : time 7.3s, size 2027241617 978374154, comp 52%, rate 277M/s 133M/s
lzop -9 : time 176.6s, size 431379371 157985635, comp 63%, rate 2M/s 0M/s
lzf : time 1.4s, size 431379371 210789363, comp 51%, rate 299M/s 146M/s
lzf : time 3.6s, size 1013573981 523007102, comp 48%, rate 282M/s 145M/s
lzf : time 6.7s, size 2027241617 972953255, comp 52%, rate 303M/s 145M/s
lzma -0 : time 27s, size 431379371 112406964, comp 74%, rate 15M/s 4M/s
lzma -1 : time 35s, size 431379371 111235594, comp 74%, rate 12M/s 3M/s
lzma: > 5 min, killed
xz -0 : time 28s, size 431379371 112424452, comp 74%, rate 15M/s 4M/s
xz -1 : time 35s, size 431379371 111252916, comp 74%, rate 12M/s 3M/s
xz: > 5 min, killed
</pre>
Columns are:
compression program
time: elapsed time of the compression program (excludes the time to flush output file to disk)
size: size of input file, size of output file
comp: compression ration (0%=no compression, 100%=file compresses into nothing)
rate: input data rate (size of input file divided by elapsed time), output data rate (size of output file
divided by elapsed time)
Machine used for testing (from /proc/cpuinfo):
Intel(R) Core(TM) i7-3820 CPU @ 3.60GHz
quad core cpu with hyper-threading (8 CPU total)
32 GB quad-channel DDR3-1600.
Script used for testing:
#!/usr/bin/perl -w
my $x = join(" ", @ARGV);
my $in = "test.mid";
my $out = "test.mid.out";
my $tout = "test.time";
my $cmd = "/usr/bin/time -o $tout -f \"%e\" /usr/bin/time $x < test.mid > test.mid.out";
print $cmd,"\n";
my $t0 = time();
system $cmd;
my $t1 = time();
my $c = `cat $tout`;
print "Elapsed time: $c";
my $t = $c;
#system "/bin/ls -l $in $out";
my $sin = -s $in;
my $sout = -s $out;
my $xt = $t1-$t0;
$xt = 1 if $xt<1;
print "Total time: $xt\n";
print sprintf("%-20s: time %5.1fs, size %12d %12d, comp %3.0f%%, rate %3dM/s %3dM/s", $x, $t, $sin,
$sout, 100*($sin-$sout)/$sin, ($sin/$t)/1e6, ($sout/$t)/1e6), "\n";
exit 0;
# end
Typical output:
[deap@deap00 pet]$ ./r.perl lzf
/usr/bin/time -o test.time -f "%e" /usr/bin/time lzf < test.mid > test.mid.out
1.27user 0.15system 0:01.44elapsed 99%CPU (0avgtext+0avgdata 2800maxresident)k
0inputs+411704outputs (0major+268minor)pagefaults 0swaps
Elapsed time: 1.44
Total time: 3
lzf : time 1.4s, size 431379371 210789363, comp 51%, rate 299M/s 146M/s
K.O. |
|
858
|
06 Feb 2013 |
Stefan Ritt | Info | Compression benchmarks | I redid the tests from Konstantin for our MEG experiment at PSI. The event structure is different, so it
is interesting how the two different experiments compare. We have an event size of 2.4 MB and a trigger
rate of ~10 Hz, so we produce a raw data rate of 24 MB/sec. A typical run contains 2000 events, so has a
size of 5 GB. Here are the results:
cat : time 7.8s, size 4960156030 4960156030, comp 0%, rate 639M/s 639M/s
gzip -1 : time 147.2s, size 4960156030 2468073901, comp 50%, rate 33M/s 16M/s
pbzip2 -p1 : time 679.6s, size 4960156030 1738127829, comp 65%, rate 7M/s 2M/s (1 CPU)
pbzip2 -p8 : time 96.1s, size 4960156030 1738127829, comp 65%, rate 51M/s 18M/s (8 CPU)
As one can see, our compression ratio is poorer (due to the quasi random noise in our waveforms), but the
difference between gzip -1 and pbzip2 is larger (15% instead 10% for DEAP). The single CPU version of
pbzip cannot sustain our DAQ rate of 24 MB, but the parallel version can. Actually we have a somehow old
dual-core dual-CPU board 2.5 GHz Xenon box, and make 8 hyper-threading CPUs out of the total 4 cores.
Interestingly the compression rate scales with 7.3 for 8 virtual cores, so hyper-threading does its job.
So we take all our data with the pbzip2 compression. The additional 15% as compared with gzip does
not sound much, but we produce raw 250 TB/year. So gzip gives us 132 TB/year and pbzip2 gives
us 98 TB/year, and we save quite some disks.
Note that you can run bzip2 (as all the other methods) already now with the current logger, if you specify
an external compression program in the ODB using the pipe functionality:
local:MEG:S]/>cd Logger/Channels/0/Settings/
[local:MEG:S]Settings>ls
Active y
Type Disk
Filename |pbzip2>/megdata/run%06d.mid.bz2
Format MIDAS
Compression 0
ODB dump y
Log messages 0
Buffer SYSTEM
Event ID -1
Trigger mask -1
Event limit 0
Byte limit 0
Subrun Byte limit 0
Tape capacity 0
Subdir format
Current filename /megdata/run197090.mid.bz2
</pre> |
|
334
|
02 Feb 2007 |
Exaos Lee | Bug Report | Compiling failed with SVN3562 under Ubuntu 6.10 | The error log is as the following:
cc -c -g -O2 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_MYSQL -DHAVE_ROOT -pthread -I/opt/root/current/include -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/system.o src/system.c
src/system.c:958: error: expected declaration specifiers or ‘...’ before ‘gettid’
src/system.c:958: warning: data definition has no type or storage class
src/system.c:958: warning: type defaults to ‘int’ in declaration of ‘_syscall0’
src/system.c: In function ‘ss_gettid’:
src/system.c:1005: warning: implicit declaration of function ‘gettid’
src/system.c: In function ‘ss_suspend_init_ipc’:
src/system.c:2948: warning: pointer targets in passing argument 3 of ‘getsockname’ differ in signedness
src/system.c: In function ‘ss_suspend’:
src/system.c:3414: warning: pointer targets in passing argument 6 of ‘recvfrom’ differ in signedness
src/system.c:3441: warning: pointer targets in passing argument 6 of ‘recvfrom’ differ in signedness
make: *** [linux/lib/system.o] 错误 1
The error might be here:
void ss_force_single_thread()
{
_single_thread = TRUE;
}
#if defined(OS_DARWIN)
// blank
#elif defined(OS_LINUX)
_syscall0(pid_t,gettid);
#endif
INT ss_gettid(void)
I have no idea about the usage of _syscall0(...). |
|
335
|
02 Feb 2007 |
Exaos Lee | Bug Report | Compiling failed with SVN3562 under Ubuntu 6.10 | I tried to solve the problem by adding a ";". It was wrong. In fact, the macro "_syscall0(..)" doesn't need the ";".
I searched and found that somebody said "the overall _syscall$magicnumber will disappear". I don't mind whether the "_syscall" disappear or not. I just want to compile the code and do my job. I deleted the additional ";" and recompiled. The error output is as the attachment [elog:335/1]. |
| Attachment 1: err.log
|
cc -c -g -O2 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_MYSQL -DHAVE_ROOT -pthread -I/opt/root/current/include -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/system.o src/system.c
src/system.c:958: error: expected declaration specifiers or ‘...’ before ‘gettid’
src/system.c:961: warning: return type defaults to ‘int’
src/system.c: In function ‘_syscall0’:
src/system.c:978: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
src/system.c:1019: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
src/system.c:1050: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
src/system.c:1165: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
src/system.c:1380: error: storage class specified for parameter ‘_daemon_flag’
src/system.c:1400: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
src/system.c:1462: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
src/system.c:1495: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
src/system.c:1532: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
src/system.c:1621: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
src/system.c:1695: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
src/system.c:1731: error: storage class specified for parameter ‘skip_mutex_handle’
src/system.c:1731: error: parameter ‘skip_mutex_handle’ is initialized
src/system.c:1760: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
src/system.c:1915: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
src/system.c:2024: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
src/system.c:2110: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
src/system.c:2181: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
src/system.c:2248: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
src/system.c:2277: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
src/system.c:2341: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
src/system.c:2379: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
src/system.c:2393: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
src/system.c:2413: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
src/system.c:2484: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
src/system.c:2546: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
src/system.c:2644: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
src/system.c:2751: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
src/system.c:2807: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
src/system.c:2871: error: storage class specified for parameter ‘SUSPEND_STRUCT’
src/system.c:2873: error: expected declaration specifiers before ‘SUSPEND_STRUCT’
src/system.c:2896: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
src/system.c:3002: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
src/system.c:3072: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
src/system.c:3132: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
src/system.c:3187: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
src/system.c:3235: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
src/system.c:3493: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
src/system.c:3547: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
src/system.c:3606: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
src/system.c:3682: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
src/system.c:3775: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
src/system.c:3901: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
src/system.c:4080: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
src/system.c:4167: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
src/system.c:4210: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
src/system.c:4297: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
src/system.c:4356: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
src/system.c:4430: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
src/system.c:4497: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
src/system.c:4558: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
src/system.c:4615: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
src/system.c:4667: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
src/system.c:4723: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
src/system.c:4779: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
src/system.c:4826: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
src/system.c:4887: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
src/system.c:4980: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
src/system.c:5049: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
src/system.c:5069: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
src/system.c:5093: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
src/system.c:5171: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
src/system.c:5222: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
src/system.c:5258: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
src/system.c:5313: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
src/system.c:5379: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
src/system.c:5645: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
src/system.c:5668: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
src/system.c:5707: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
src/system.c:5769: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
src/system.c:5853: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
src/system.c:5883: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
In file included from /usr/include/math.h:71,
from src/system.c:5897:
/usr/include/bits/mathcalls.h:55: error: storage class specified for parameter ‘acos’
/usr/include/bits/mathcalls.h:55: error: storage class specified for parameter ‘__acos’
/usr/include/bits/mathcalls.h:57: error: storage class specified for parameter ‘asin’
/usr/include/bits/mathcalls.h:57: error: storage class specified for parameter ‘__asin’
/usr/include/bits/mathcalls.h:59: error: storage class specified for parameter ‘atan’
/usr/include/bits/mathcalls.h:59: error: storage class specified for parameter ‘__atan’
/usr/include/bits/mathcalls.h:61: error: storage class specified for parameter ‘atan2’
/usr/include/bits/mathcalls.h:61: error: storage class specified for parameter ‘__atan2’
/usr/include/bits/mathcalls.h:64: error: storage class specified for parameter ‘cos’
/usr/include/bits/mathcalls.h:64: error: storage class specified for parameter ‘__cos’
/usr/include/bits/mathcalls.h:66: error: storage class specified for parameter ‘sin’
/usr/include/bits/mathcalls.h:66: error: storage class specified for parameter ‘__sin’
/usr/include/bits/mathcalls.h:68: error: storage class specified for parameter ‘tan’
/usr/include/bits/mathcalls.h:68: error: storage class specified for parameter ‘__tan’
/usr/include/bits/mathcalls.h:73: error: storage class specified for parameter ‘cosh’
/usr/include/bits/mathcalls.h:73: error: storage class specified for parameter ‘__cosh’
/usr/include/bits/mathcalls.h:75: error: storage class specified for parameter ‘sinh’
/usr/include/bits/mathcalls.h:75: error: storage class specified for parameter ‘__sinh’
/usr/include/bits/mathcalls.h:77: error: storage class specified for parameter ‘tanh’
/usr/include/bits/mathcalls.h:77: error: storage class specified for parameter ‘__tanh’
/usr/include/bits/mathcalls.h:89: error: storage class specified for parameter ‘acosh’
/usr/include/bits/mathcalls.h:89: error: storage class specified for parameter ‘__acosh’
/usr/include/bits/mathcalls.h:91: error: storage class specified for parameter ‘asinh’
/usr/include/bits/mathcalls.h:91: error: storage class specified for parameter ‘__asinh’
/usr/include/bits/mathcalls.h:93: error: storage class specified for parameter ‘atanh’
/usr/include/bits/mathcalls.h:93: error: storage class specified for parameter ‘__atanh’
/usr/include/bits/mathcalls.h:101: error: storage class specified for parameter ‘exp’
/usr/include/bits/mathcalls.h:101: error: storage class specified for parameter ‘__exp’
/usr/include/bits/mathcalls.h:104: error: storage class specified for parameter ‘frexp’
/usr/include/bits/mathcalls.h:104: error: storage class specified for parameter ‘__frexp’
/usr/include/bits/mathcalls.h:107: error: storage class specified for parameter ‘ldexp’
/usr/include/bits/mathcalls.h:107: error: storage class specified for parameter ‘__ldexp’
/usr/include/bits/mathcalls.h:110: error: storage class specified for parameter ‘log’
/usr/include/bits/mathcalls.h:110: error: storage class specified for parameter ‘__log’
/usr/include/bits/mathcalls.h:113: error: storage class specified for parameter ‘log10’
/usr/include/bits/mathcalls.h:113: error: storage class specified for parameter ‘__log10’
/usr/include/bits/mathcalls.h:116: error: storage class specified for parameter ‘modf’
/usr/include/bits/mathcalls.h:116: error: storage class specified for parameter ‘__modf’
/usr/include/bits/mathcalls.h:129: error: storage class specified for parameter ‘expm1’
/usr/include/bits/mathcalls.h:129: error: storage class specified for parameter ‘__expm1’
/usr/include/bits/mathcalls.h:132: error: storage class specified for parameter ‘log1p’
/usr/include/bits/mathcalls.h:132: error: storage class specified for parameter ‘__log1p’
/usr/include/bits/mathcalls.h:135: error: storage class specified for parameter ‘logb’
/usr/include/bits/mathcalls.h:135: error: storage class specified for parameter ‘__logb’
/usr/include/bits/mathcalls.h:154: error: storage class specified for parameter ‘pow’
/usr/include/bits/mathcalls.h:154: error: storage class specified for parameter ‘__pow’
/usr/include/bits/mathcalls.h:157: error: storage class specified for parameter ‘sqrt’
/usr/include/bits/mathcalls.h:157: error: storage class specified for parameter ‘__sqrt’
/usr/include/bits/mathcalls.h:163: error: storage class specified for parameter ‘hypot’
/usr/include/bits/mathcalls.h:163: error: storage class specified for parameter ‘__hypot’
/usr/include/bits/mathcalls.h:170: error: storage class specified for parameter ‘cbrt’
/usr/include/bits/mathcalls.h:170: error: storage class specified for parameter ‘__cbrt’
/usr/include/bits/mathcalls.h:179: error: storage class specified for parameter ‘ceil’
/usr/include/bits/mathcalls.h:179: error: storage class specified for parameter ‘__ceil’
/usr/include/bits/mathcalls.h:182: error: storage class specified for parameter ‘fabs’
/usr/include/bits/mathcalls.h:182: error: storage class specified for parameter ‘__fabs’
/usr/include/bits/mathcalls.h:185: error: storage class specified for parameter ‘floor’
/usr/include/bits/mathcalls.h:185: error: storage class specified for parameter ‘__floor’
/usr/include/bits/mathcalls.h:188: error: storage class specified for parameter ‘fmod’
/usr/include/bits/mathcalls.h:188: error: storage class specified for parameter ‘__fmod’
/usr/include/bits/mathcalls.h:193: error: storage class specified for parameter ‘__isinf’
/usr/include/bits/mathcalls.h:196: error: storage class specified for parameter ‘__finite’
/usr/include/bits/mathcalls.h:202: error: storage class specified for parameter ‘isinf’
/usr/include/bits/mathcalls.h:205: error: storage class specified for parameter ‘finite’
/usr/include/bits/mathcalls.h:208: error: storage class specified for parameter ‘drem’
/usr/include/bits/mathcalls.h:208: error: storage class specified for parameter ‘__drem’
/usr/include/bits/mathcalls.h:212: error: storage class specified for parameter ‘significand’
/usr/include/bits/mathcalls.h:212: error: storage class specified for parameter ‘__significand’
/usr/include/bits/mathcalls.h:218: error: storage class specified for parameter ‘copysign’
/usr/include/bits/mathcalls.h:218: error: storage class specified for parameter ‘__copysign’
/usr/include/bits/mathcalls.h:231: error: storage class specified for parameter ‘__isnan’
/usr/include/bits/mathcalls.h:235: error: storage class specified for parameter ‘isnan’
/usr/include/bits/mathcalls.h:238: error: storage class specified for parameter ‘j0’
/usr/include/bits/mathcalls.h:238: error: storage class specified for parameter ‘__j0’
/usr/include/bits/mathcalls.h:239: error: storage class specified for parameter ‘j1’
/usr/include/bits/mathcalls.h:239: error: storage class specified for parameter ‘__j1’
/usr/include/bits/mathcalls.h:240: error: storage class specified for parameter ‘jn’
/usr/include/bits/mathcalls.h:240: error: storage class specified for parameter ‘__jn’
/usr/include/bits/mathcalls.h:241: error: storage class specified for parameter ‘y0’
/usr/include/bits/mathcalls.h:241: error: storage class specified for parameter ‘__y0’
/usr/include/bits/mathcalls.h:242: error: storage class specified for parameter ‘y1’
/usr/include/bits/mathcalls.h:242: error: storage class specified for parameter ‘__y1’
/usr/include/bits/mathcalls.h:243: error: storage class specified for parameter ‘yn’
/usr/include/bits/mathcalls.h:243: error: storage class specified for parameter ‘__yn’
/usr/include/bits/mathcalls.h:250: error: storage class specified for parameter ‘erf’
/usr/include/bits/mathcalls.h:250: error: storage class specified for parameter ‘__erf’
/usr/include/bits/mathcalls.h:251: error: storage class specified for parameter ‘erfc’
/usr/include/bits/mathcalls.h:251: error: storage class specified for parameter ‘__erfc’
/usr/include/bits/mathcalls.h:252: error: storage class specified for parameter ‘lgamma’
/usr/include/bits/mathcalls.h:252: error: storage class specified for parameter ‘__lgamma’
/usr/include/bits/mathcalls.h:265: error: storage class specified for parameter ‘gamma’
/usr/include/bits/mathcalls.h:265: error: storage class specified for parameter ‘__gamma’
/usr/include/bits/mathcalls.h:272: error: storage class specified for parameter ‘lgamma_r’
/usr/include/bits/mathcalls.h:272: error: storage class specified for parameter ‘__lgamma_r’
/usr/include/bits/mathcalls.h:280: error: storage class specified for parameter ‘rint’
/usr/include/bits/mathcalls.h:280: error: storage class specified for parameter ‘__rint’
/usr/include/bits/mathcalls.h:283: error: storage class specified for parameter ‘nextafter’
/usr/include/bits/mathcalls.h:283: error: storage class specified for parameter ‘__nextafter’
/usr/include/bits/mathcalls.h:289: error: storage class specified for parameter ‘remainder’
/usr/include/bits/mathcalls.h:289: error: storage class specified for parameter ‘__remainder’
/usr/include/bits/mathcalls.h:293: error: storage class specified for parameter ‘scalbn’
/usr/include/bits/mathcalls.h:293: error: storage class specified for parameter ‘__scalbn’
/usr/include/bits/mathcalls.h:297: error: storage class specified for parameter ‘ilogb’
/usr/include/bits/mathcalls.h:297: error: storage class specified for parameter ‘__ilogb’
/usr/include/bits/mathcalls.h:364: error: storage class specified for parameter ‘scalb’
/usr/include/bits/mathcalls.h:364: error: storage class specified for parameter ‘__scalb’
In file included from /usr/include/math.h:94,
from src/system.c:5897:
/usr/include/bits/mathcalls.h:55: error: storage class specified for parameter ‘acosf’
/usr/include/bits/mathcalls.h:55: error: storage class specified for parameter ‘__acosf’
/usr/include/bits/mathcalls.h:57: error: storage class specified for parameter ‘asinf’
/usr/include/bits/mathcalls.h:57: error: storage class specified for parameter ‘__asinf’
/usr/include/bits/mathcalls.h:59: error: storage class specified for parameter ‘atanf’
/usr/include/bits/mathcalls.h:59: error: storage class specified for parameter ‘__atanf’
/usr/include/bits/mathcalls.h:61: error: storage class specified for parameter ‘atan2f’
/usr/include/bits/mathcalls.h:61: error: storage class specified for parameter ‘__atan2f’
/usr/include/bits/mathcalls.h:64: error: storage class specified for parameter ‘cosf’
/usr/include/bits/mathcalls.h:64: error: storage class specified for parameter ‘__cosf’
/usr/include/bits/mathcalls.h:66: error: storage class specified for parameter ‘sinf’
/usr/include/bits/mathcalls.h:66: error: storage class specified for parameter ‘__sinf’
/usr/include/bits/mathcalls.h:68: error: storage class specified for parameter ‘tanf’
/usr/include/bits/mathcalls.h:68: error: storage class specified for parameter ‘__tanf’
/usr/include/bits/mathcalls.h:73: error: storage class specified for parameter ‘coshf’
/usr/include/bits/mathcalls.h:73: error: storage class specified for parameter ‘__coshf’
/usr/include/bits/mathcalls.h:75: error: storage class specified for parameter ‘sinhf’
/usr/include/bits/mathcalls.h:75: error: storage class specified for parameter ‘__sinhf’
/usr/include/bits/mathcalls.h:77: error: storage class specified for parameter ‘tanhf’
/usr/include/bits/mathcalls.h:77: error: storage class specified for parameter ‘__tanhf’
/usr/include/bits/mathcalls.h:89: error: storage class specified for parameter ‘acoshf’
/usr/include/bits/mathcalls.h:89: error: storage class specified for parameter ‘__acoshf’
/usr/include/bits/mathcalls.h:91: error: storage class specified for parameter ‘asinhf’
/usr/include/bits/mathcalls.h:91: error: storage class specified for parameter ‘__asinhf’
/usr/include/bits/mathcalls.h:93: error: storage class specified for parameter ‘atanhf’
/usr/include/bits/mathcalls.h:93: error: storage class specified for parameter ‘__atanhf’
/usr/include/bits/mathcalls.h:101: error: storage class specified for parameter ‘expf’
/usr/include/bits/mathcalls.h:101: error: storage class specified for parameter ‘__expf’
/usr/include/bits/mathcalls.h:104: error: storage class specified for parameter ‘frexpf’
/usr/include/bits/mathcalls.h:104: error: storage class specified for parameter ‘__frexpf’
/usr/include/bits/mathcalls.h:107: error: storage class specified for parameter ‘ldexpf’
/usr/include/bits/mathcalls.h:107: error: storage class specified for parameter ‘__ldexpf’
/usr/include/bits/mathcalls.h:110: error: storage class specified for parameter ‘logf’
/usr/include/bits/mathcalls.h:110: error: storage class specified for parameter ‘__logf’
/usr/include/bits/mathcalls.h:113: error: storage class specified for parameter ‘log10f’
/usr/include/bits/mathcalls.h:113: error: storage class specified for parameter ‘__log10f’
/usr/include/bits/mathcalls.h:116: error: storage class specified for parameter ‘modff’
/usr/include/bits/mathcalls.h:116: error: storage class specified for parameter ‘__modff’
/usr/include/bits/mathcalls.h:129: error: storage class specified for parameter ‘expm1f’
/usr/include/bits/mathcalls.h:129: error: storage class specified for parameter ‘__expm1f’
/usr/include/bits/mathcalls.h:132: error: storage class specified for parameter ‘log1pf’
/usr/include/bits/mathcalls.h:132: error: storage class specified for parameter ‘__log1pf’
/usr/include/bits/mathcalls.h:135: error: storage class specified for parameter ‘logbf’
/usr/include/bits/mathcalls.h:135: error: storage class specified for parameter ‘__logbf’
/usr/include/bits/mathcalls.h:154: error: storage class specified for parameter ‘powf’
/usr/include/bits/mathcalls.h:154: error: storage class specified for parameter ‘__powf’
/usr/include/bits/mathcalls.h:157: error: storage class specified for parameter ‘sqrtf’
/usr/include/bits/mathcalls.h:157: error: storage class specified for parameter ‘__sqrtf’
/usr/include/bits/mathcalls.h:163: error: storage class specified for parameter ‘hypotf’
/usr/include/bits/mathcalls.h:163: error: storage class specified for parameter ‘__hypotf’
/usr/include/bits/mathcalls.h:170: error: storage class specified for parameter ‘cbrtf’
/usr/include/bits/mathcalls.h:170: error: storage class specified for parameter ‘__cbrtf’
/usr/include/bits/mathcalls.h:179: error: storage class specified for parameter ‘ceilf’
/usr/include/bits/mathcalls.h:179: error: storage class specified for parameter ‘__ceilf’
/usr/include/bits/mathcalls.h:182: error: storage class specified for parameter ‘fabsf’
/usr/include/bits/mathcalls.h:182: error: storage class specified for parameter ‘__fabsf’
/usr/include/bits/mathcalls.h:185: error: storage class specified for parameter ‘floorf’
/usr/include/bits/mathcalls.h:185: error: storage class specified for parameter ‘__floorf’
/usr/include/bits/mathcalls.h:188: error: storage class specified for parameter ‘fmodf’
/usr/include/bits/mathcalls.h:188: error: storage class specified for parameter ‘__fmodf’
/usr/include/bits/mathcalls.h:193: error: storage class specified for parameter ‘__isinff’
/usr/include/bits/mathcalls.h:196: error: storage class specified for parameter ‘__finitef’
/usr/include/bits/mathcalls.h:202: error: storage class specified for parameter ‘isinff’
/usr/include/bits/mathcalls.h:205: error: storage class specified for parameter ‘finitef’
/usr/include/bits/mathcalls.h:208: error: storage class specified for parameter ‘dremf’
/usr/include/bits/mathcalls.h:208: error: storage class specified for parameter ‘__dremf’
/usr/include/bits/mathcalls.h:212: error: storage class specified for parameter ‘significandf’
/usr/include/bits/mathcalls.h:212: error: storage class specified for parameter ‘__significandf’
/usr/include/bits/mathcalls.h:218: error: storage class specified for parameter ‘copysignf’
/usr/include/bits/mathcalls.h:218: error: storage class specified for parameter ‘__copysignf’
/usr/include/bits/mathcalls.h:231: error: storage class specified for parameter ‘__isnanf’
/usr/include/bits/mathcalls.h:235: error: storage class specified for parameter ‘isnanf’
/usr/include/bits/mathcalls.h:238: error: storage class specified for parameter ‘j0f’
/usr/include/bits/mathcalls.h:238: error: storage class specified for parameter ‘__j0f’
/usr/include/bits/mathcalls.h:239: error: storage class specified for parameter ‘j1f’
/usr/include/bits/mathcalls.h:239: error: storage class specified for parameter ‘__j1f’
/usr/include/bits/mathcalls.h:240: error: storage class specified for parameter ‘jnf’
/usr/include/bits/mathcalls.h:240: error: storage class specified for parameter ‘__jnf’
/usr/include/bits/mathcalls.h:241: error: storage class specified for parameter ‘y0f’
/usr/include/bits/mathcalls.h:241: error: storage class specified for parameter ‘__y0f’
/usr/include/bits/mathcalls.h:242: error: storage class specified for parameter ‘y1f’
/usr/include/bits/mathcalls.h:242: error: storage class specified for parameter ‘__y1f’
/usr/include/bits/mathcalls.h:243: error: storage class specified for parameter ‘ynf’
/usr/include/bits/mathcalls.h:243: error: storage class specified for parameter ‘__ynf’
/usr/include/bits/mathcalls.h:250: error: storage class specified for parameter ‘erff’
/usr/include/bits/mathcalls.h:250: error: storage class specified for parameter ‘__erff’
/usr/include/bits/mathcalls.h:251: error: storage class specified for parameter ‘erfcf’
/usr/include/bits/mathcalls.h:251: error: storage class specified for parameter ‘__erfcf’
/usr/include/bits/mathcalls.h:252: error: storage class specified for parameter ‘lgammaf’
/usr/include/bits/mathcalls.h:252: error: storage class specified for parameter ‘__lgammaf’
/usr/include/bits/mathcalls.h:265: error: storage class specified for parameter ‘gammaf’
/usr/include/bits/mathcalls.h:265: error: storage class specified for parameter ‘__gammaf’
/usr/include/bits/mathcalls.h:272: error: storage class specified for parameter ‘lgammaf_r’
/usr/include/bits/mathcalls.h:272: error: storage class specified for parameter ‘__lgammaf_r’
/usr/include/bits/mathcalls.h:280: error: storage class specified for parameter ‘rintf’
/usr/include/bits/mathcalls.h:280: error: storage class specified for parameter ‘__rintf’
/usr/include/bits/mathcalls.h:283: error: storage class specified for parameter ‘nextafterf’
/usr/include/bits/mathcalls.h:283: error: storage class specified for parameter ‘__nextafterf’
/usr/include/bits/mathcalls.h:289: error: storage class specified for parameter ‘remainderf’
/usr/include/bits/mathcalls.h:289: error: storage class specified for parameter ‘__remainderf’
/usr/include/bits/mathcalls.h:293: error: storage class specified for parameter ‘scalbnf’
/usr/include/bits/mathcalls.h:293: error: storage class specified for parameter ‘__scalbnf’
/usr/include/bits/mathcalls.h:297: error: storage class specified for parameter ‘ilogbf’
/usr/include/bits/mathcalls.h:297: error: storage class specified for parameter ‘__ilogbf’
/usr/include/bits/mathcalls.h:364: error: storage class specified for parameter ‘scalbf’
/usr/include/bits/mathcalls.h:364: error: storage class specified for parameter ‘__scalbf’
In file included from /usr/include/math.h:141,
from src/system.c:5897:
/usr/include/bits/mathcalls.h:55: error: storage class specified for parameter ‘acosl’
/usr/include/bits/mathcalls.h:55: error: storage class specified for parameter ‘__acosl’
/usr/include/bits/mathcalls.h:57: error: storage class specified for parameter ‘asinl’
/usr/include/bits/mathcalls.h:57: error: storage class specified for parameter ‘__asinl’
/usr/include/bits/mathcalls.h:59: error: storage class specified for parameter ‘atanl’
/usr/include/bits/mathcalls.h:59: error: storage class specified for parameter ‘__atanl’
... 133 more lines ...
|
|
635
|
06 Sep 2009 |
Exaos Lee | Bug Report | Compiling error of "src/history_odbc.cxx" | Version svn-r4556, I got a compiling error as below:
/opt/DAQ/bot/midas/src/history_odbc.cxx: In member function 'virtual int
SqlODBC::GetNumRows()':
/opt/DAQ/bot/midas/src/history_odbc.cxx:589: error: cannot convert 'SQLINTEGER*'
to 'long int*' for argument '2' to 'SQLRETURN SQLRowCount(void*, long int*)'
/opt/DAQ/bot/midas/src/history_odbc.cxx: In member function 'virtual const char*
SqlODBC::GetColumn(int)':
/opt/DAQ/bot/midas/src/history_odbc.cxx:638: error: cannot convert 'SQLINTEGER*'
to 'long int*' for argument '6' to 'SQLRETURN SQLGetData(void*, SQLUSMALLINT,
SQLSMALLINT, void*, long int, long int*)'
make[2]: *** [CMakeFiles/midas-static.dir/src/history_odbc.cxx.o] Error 1
make[2]: Leaving directory `/opt/DAQ/bot/midas/build'
make[1]: *** [CMakeFiles/midas-static.dir/all] Error 2
make[1]: Leaving directory `/opt/DAQ/bot/midas/build'
The detail error log is attached. I used my CMake script without any optimization flags. I will try the default Makefile again. |
| Attachment 1: build-err.log
|
/usr/bin/cmake -H/opt/DAQ/bot/midas -B/opt/DAQ/bot/midas/build --check-build-system CMakeFiles/Makefile.cmake 0
/usr/bin/cmake -E cmake_progress_start /opt/DAQ/bot/midas/build/CMakeFiles /opt/DAQ/bot/midas/build/CMakeFiles/progress.make
make -f CMakeFiles/Makefile2 all
make[1]: Entering directory `/opt/DAQ/bot/midas/build'
make -f CMakeFiles/midas-static.dir/build.make CMakeFiles/midas-static.dir/depend
make[2]: Entering directory `/opt/DAQ/bot/midas/build'
cd /opt/DAQ/bot/midas/build && /usr/bin/cmake -E cmake_depends "Unix Makefiles" /opt/DAQ/bot/midas /opt/DAQ/bot/midas /opt/DAQ/bot/midas/build /opt/DAQ/bot/midas/build /opt/DAQ/bot/midas/build/CMakeFiles/midas-static.dir/DependInfo.cmake --color=
make[2]: Leaving directory `/opt/DAQ/bot/midas/build'
make -f CMakeFiles/midas-static.dir/build.make CMakeFiles/midas-static.dir/build
make[2]: Entering directory `/opt/DAQ/bot/midas/build'
/usr/bin/cmake -E cmake_progress_report /opt/DAQ/bot/midas/build/CMakeFiles 41
[ 1%] Building CXX object CMakeFiles/midas-static.dir/src/history_odbc.cxx.o
/usr/bin/c++ -DOS_LINUX -D_LARGEFILE64_SOURCE -DHAVE_STRLCPY -DINCLUDE_FTPLIB -DHAVE_ODBC -DHAVE_ZLIB -I/opt/DAQ/bot/midas/include -I/opt/DAQ/bot/mxml -o CMakeFiles/midas-static.dir/src/history_odbc.cxx.o -c /opt/DAQ/bot/midas/src/history_odbc.cxx
/opt/DAQ/bot/midas/src/history_odbc.cxx:95: warning: deprecated conversion from string constant to 'char*'
/opt/DAQ/bot/midas/src/history_odbc.cxx:95: warning: deprecated conversion from string constant to 'char*'
/opt/DAQ/bot/midas/src/history_odbc.cxx:95: warning: deprecated conversion from string constant to 'char*'
/opt/DAQ/bot/midas/src/history_odbc.cxx:95: warning: deprecated conversion from string constant to 'char*'
/opt/DAQ/bot/midas/src/history_odbc.cxx:95: warning: deprecated conversion from string constant to 'char*'
/opt/DAQ/bot/midas/src/history_odbc.cxx:95: warning: deprecated conversion from string constant to 'char*'
/opt/DAQ/bot/midas/src/history_odbc.cxx:95: warning: deprecated conversion from string constant to 'char*'
/opt/DAQ/bot/midas/src/history_odbc.cxx:95: warning: deprecated conversion from string constant to 'char*'
/opt/DAQ/bot/midas/src/history_odbc.cxx:95: warning: deprecated conversion from string constant to 'char*'
/opt/DAQ/bot/midas/src/history_odbc.cxx:95: warning: deprecated conversion from string constant to 'char*'
/opt/DAQ/bot/midas/src/history_odbc.cxx:95: warning: deprecated conversion from string constant to 'char*'
/opt/DAQ/bot/midas/src/history_odbc.cxx:95: warning: deprecated conversion from string constant to 'char*'
/opt/DAQ/bot/midas/src/history_odbc.cxx:95: warning: deprecated conversion from string constant to 'char*'
/opt/DAQ/bot/midas/src/history_odbc.cxx:95: warning: deprecated conversion from string constant to 'char*'
/opt/DAQ/bot/midas/src/history_odbc.cxx:95: warning: deprecated conversion from string constant to 'char*'
/opt/DAQ/bot/midas/src/history_odbc.cxx:95: warning: deprecated conversion from string constant to 'char*'
/opt/DAQ/bot/midas/src/history_odbc.cxx:95: warning: deprecated conversion from string constant to 'char*'
/opt/DAQ/bot/midas/src/history_odbc.cxx:116: warning: deprecated conversion from string constant to 'char*'
/opt/DAQ/bot/midas/src/history_odbc.cxx:116: warning: deprecated conversion from string constant to 'char*'
/opt/DAQ/bot/midas/src/history_odbc.cxx:116: warning: deprecated conversion from string constant to 'char*'
/opt/DAQ/bot/midas/src/history_odbc.cxx:116: warning: deprecated conversion from string constant to 'char*'
/opt/DAQ/bot/midas/src/history_odbc.cxx:116: warning: deprecated conversion from string constant to 'char*'
/opt/DAQ/bot/midas/src/history_odbc.cxx:116: warning: deprecated conversion from string constant to 'char*'
/opt/DAQ/bot/midas/src/history_odbc.cxx:116: warning: deprecated conversion from string constant to 'char*'
/opt/DAQ/bot/midas/src/history_odbc.cxx:116: warning: deprecated conversion from string constant to 'char*'
/opt/DAQ/bot/midas/src/history_odbc.cxx:116: warning: deprecated conversion from string constant to 'char*'
/opt/DAQ/bot/midas/src/history_odbc.cxx:116: warning: deprecated conversion from string constant to 'char*'
/opt/DAQ/bot/midas/src/history_odbc.cxx:116: warning: deprecated conversion from string constant to 'char*'
/opt/DAQ/bot/midas/src/history_odbc.cxx:116: warning: deprecated conversion from string constant to 'char*'
/opt/DAQ/bot/midas/src/history_odbc.cxx:116: warning: deprecated conversion from string constant to 'char*'
/opt/DAQ/bot/midas/src/history_odbc.cxx:116: warning: deprecated conversion from string constant to 'char*'
/opt/DAQ/bot/midas/src/history_odbc.cxx:116: warning: deprecated conversion from string constant to 'char*'
/opt/DAQ/bot/midas/src/history_odbc.cxx:116: warning: deprecated conversion from string constant to 'char*'
/opt/DAQ/bot/midas/src/history_odbc.cxx:116: warning: deprecated conversion from string constant to 'char*'
/opt/DAQ/bot/midas/src/history_odbc.cxx:136: warning: deprecated conversion from string constant to 'char*'
/opt/DAQ/bot/midas/src/history_odbc.cxx:136: warning: deprecated conversion from string constant to 'char*'
/opt/DAQ/bot/midas/src/history_odbc.cxx:136: warning: deprecated conversion from string constant to 'char*'
/opt/DAQ/bot/midas/src/history_odbc.cxx:136: warning: deprecated conversion from string constant to 'char*'
/opt/DAQ/bot/midas/src/history_odbc.cxx:136: warning: deprecated conversion from string constant to 'char*'
/opt/DAQ/bot/midas/src/history_odbc.cxx:136: warning: deprecated conversion from string constant to 'char*'
/opt/DAQ/bot/midas/src/history_odbc.cxx:136: warning: deprecated conversion from string constant to 'char*'
/opt/DAQ/bot/midas/src/history_odbc.cxx:136: warning: deprecated conversion from string constant to 'char*'
/opt/DAQ/bot/midas/src/history_odbc.cxx:136: warning: deprecated conversion from string constant to 'char*'
/opt/DAQ/bot/midas/src/history_odbc.cxx:136: warning: deprecated conversion from string constant to 'char*'
/opt/DAQ/bot/midas/src/history_odbc.cxx:136: warning: deprecated conversion from string constant to 'char*'
/opt/DAQ/bot/midas/src/history_odbc.cxx:136: warning: deprecated conversion from string constant to 'char*'
/opt/DAQ/bot/midas/src/history_odbc.cxx:136: warning: deprecated conversion from string constant to 'char*'
/opt/DAQ/bot/midas/src/history_odbc.cxx:136: warning: deprecated conversion from string constant to 'char*'
/opt/DAQ/bot/midas/src/history_odbc.cxx:136: warning: deprecated conversion from string constant to 'char*'
/opt/DAQ/bot/midas/src/history_odbc.cxx:136: warning: deprecated conversion from string constant to 'char*'
/opt/DAQ/bot/midas/src/history_odbc.cxx:136: warning: deprecated conversion from string constant to 'char*'
/opt/DAQ/bot/midas/src/history_odbc.cxx: In member function 'virtual int SqlODBC::GetNumRows()':
/opt/DAQ/bot/midas/src/history_odbc.cxx:589: error: cannot convert 'SQLINTEGER*' to 'long int*' for argument '2' to 'SQLRETURN SQLRowCount(void*, long int*)'
/opt/DAQ/bot/midas/src/history_odbc.cxx: In member function 'virtual const char* SqlODBC::GetColumn(int)':
/opt/DAQ/bot/midas/src/history_odbc.cxx:638: error: cannot convert 'SQLINTEGER*' to 'long int*' for argument '6' to 'SQLRETURN SQLGetData(void*, SQLUSMALLINT, SQLSMALLINT, void*, long int, long int*)'
make[2]: *** [CMakeFiles/midas-static.dir/src/history_odbc.cxx.o] Error 1
make[2]: Leaving directory `/opt/DAQ/bot/midas/build'
make[1]: *** [CMakeFiles/midas-static.dir/all] Error 2
make[1]: Leaving directory `/opt/DAQ/bot/midas/build'
make: *** [all] Error 2
|
|