Has anyone noticed errors or event.effect errors when using Version 3.2 of Circuits? I've received the message:
Apr 15 03:48:05 **** resilient-circuits[11462]: event.effects -= 1
Apr 15 03:48:05 **** resilient-circuits[11462]: *AttributeError: 'ThreatServiceLookupEvent' object has no attribute 'effects'*
which seems to be coming from circuits. Specifically line 738 of the the Manager.py script.
[Manager.py]: <https://github.com/circuits/circuits/blob/59b2a7be553fa788d06e7575b39a5eb2ec96f884/circuits/core/manager.py#L738>
Related
I am looking for a way to show the results of the file "tcp-variants-comparison.cc" under ns3 (3.28) used with Ubuntu 18.04.
I found here an old topic from 2013, but it seems not to work correctly in my current environment.
P.S: I am a newbie in ns3, so i will appreciate any help.
regards
cedkhader
Running ./waf --run "tcp-variants-comparison --tracing=1" yields the following files:
-rw-rw-r-- 1 112271415 Aug 5 15:52 TcpVariantsComparison-ascii
-rw-rw-r-- 1 401623 Aug 5 15:52 TcpVariantsComparison-cwnd.data
-rw-rw-r-- 1 1216177 Aug 5 15:52 TcpVariantsComparison-inflight.data
-rw-rw-r-- 1 947619 Aug 5 15:52 TcpVariantsComparison-next-rx.data
-rw-rw-r-- 1 955550 Aug 5 15:52 TcpVariantsComparison-next-tx.data
-rw-rw-r-- 1 38 Aug 5 15:51 TcpVariantsComparison-rto.data
-rw-rw-r-- 1 482134 Aug 5 15:52 TcpVariantsComparison-rtt.data
-rw-rw-r-- 1 346427 Aug 5 15:52 TcpVariantsComparison-ssth.data
You can use other command line arguments to generate the desired output, see list below.
Program Arguments:
--transport_prot: Transport protocol to use: TcpNewReno, TcpHybla, TcpHighSpeed, TcpHtcp, TcpVegas, TcpScalable, TcpVeno, TcpBic, TcpYeah, TcpIllinois, TcpWestwood, TcpWestwoodPlus, TcpLedbat [TcpWestwood]
--error_p: Packet error rate [0]
--bandwidth: Bottleneck bandwidth [2Mbps]
--delay: Bottleneck delay [0.01ms]
--access_bandwidth: Access link bandwidth [10Mbps]
--access_delay: Access link delay [45ms]
--tracing: Flag to enable/disable tracing [true]
--prefix_name: Prefix of output trace file [TcpVariantsComparison]
--data: Number of Megabytes of data to transmit [0]
--mtu: Size of IP packets to send in bytes [400]
--num_flows: Number of flows [1]
--duration: Time to allow flows to run in seconds [100]
--run: Run index (for setting repeatable seeds) [0]
--flow_monitor: Enable flow monitor [false]
--pcap_tracing: Enable or disable PCAP tracing [false]
--queue_disc_type: Queue disc type for gateway (e.g. ns3::CoDelQueueDisc) [ns3::PfifoFastQueueDisc]
--sack: Enable or disable SACK option [true]
in ns3.36.1 I used this command
./ns3 run examples/tcp/tcp-variants-comparison.cc -- --tracing=1
and output look like this
TcpVariantsComparison-ascii
TcpVariantsComparison-cwnd.data
TcpVariantsComparison-inflight.data
TcpVariantsComparison-next-rx.data
TcpVariantsComparison-next-tx.data
TcpVariantsComparison-rto.data
TcpVariantsComparison-rtt.data
TcpVariantsComparison-ssth.data
I've coded a standalone Objective C command application. If I run it through a LaunchDaemon, it runs just fine when connected by an ObjC client application over DistriutedObjects communication. If I run it at command line, it runs just fine. If I run it when called by a Bash script, it runs just fine. However, in various ways that I've attempted to run this through the root user's crontab, it does a crash report about pointer allocation:
Apr 14 05:27:00 volomike cron[72531]: cron(72531,0x7fff7d2fa000) malloc: *** error for object 0x7fb9c8400213: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
Apr 14 05:27:00 volomike diagnosticd[70689]: error evaluating process info - pid: 72531, puniqueid: 72531
Apr 14 05:27:00 volomike com.apple.xpc.launchd[1] (com.vix.cron[72531]): Service exited due to signal: Abort trap: 6
Apr 14 05:27:00 volomike com.apple.xpc.launchd[1] (com.apple.ReportCrash.Root[72550]): Endpoint has been activated through legacy launch(3) APIs. Please switch to XPC or bootstrap_check_in(): com.apple.ReportCrash.DirectoryService
Apr 14 05:27:00 volomike ReportCrash[72550]: Saved crash report for cron[72531] version 39 to /Library/Logs/DiagnosticReports/cron_2016-04-14-052700_volomike.crash
The significant part of that crash report reads:
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY
Application Specific Information:
abort() called
*** error for object 0x7fb9c8400213: pointer being freed was not allocated
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x00007fff9490ff06 __pthread_kill + 10
1 libsystem_pthread.dylib 0x00007fff9c45e4ec pthread_kill + 90
2 libsystem_c.dylib 0x00007fff9345b6e7 abort + 129
3 libsystem_malloc.dylib 0x00007fff9c02f041 free + 425
4 cron 0x000000010367aa41 0x103677000 + 14913
5 cron 0x000000010367a7e4 0x103677000 + 14308
6 cron 0x0000000103679572 0x103677000 + 9586
7 cron 0x000000010367925a 0x103677000 + 8794
8 cron 0x000000010367885e 0x103677000 + 6238
9 libdyld.dylib 0x00007fff949835ad start + 1
In the various ways, I've done it with these various cron lines, but they crash immediately when trying to call the command, and even when I have NSLog() writing stuff to /var/log/system.log all the way from the start of main to the end of the application, nothing writes -- it's like when cron tries to call my command, it dies immediately with a crash report about pointer allocation.
41 5 * * * /bin/bash '/Applications/My App.app/Contents/Resources/mytoolcommand.sh' /q /sched
41 5 * * * /bin/bash '/Applications/My App.app/Contents/Resources/mytoolcommand.sh' /q /sched &
41 5 * * * '/Applications/My App.app/Contents/Resources/mytoolcommand' /q /sched
41 5 * * * '/Applications/My App.app/Contents/Resources/mytoolcommand' /q /sched &
Note again that if I do '/Applications/My App.app/Contents/Resources/mytoolcommand.sh' /q /sched, it runs just fine, as does /bin/bash '/Applications/My App.app/Contents/Resources/mytoolcommand.sh' /q /sched, as does '/Applications/My App.app/Contents/Resources/mytoolcommand' /q /sched
I even did a variation where cron called my mytoolcommand.sh script and simply wrote Hello World to /tmp/out.txt, and it ran just fine. So, I know my crontab is working.
Can you help me figure out what I'm doing wrong? Some suspected possible issues:
Perhaps OSX El Capitan is shutting my application down for some reason, such as not being signed properly. (I'm debugging right now. I never had signature issues come up before unless it dealt with .app folders. Besides, I can run it just fine from command line without having a signature warning.)
I have debug messages loading from main() right off the bat. They should be writing to /var/log/system.log, but they're not. This tells me the application is crashing immediately when called by cron. So, is there something special I need to load into my application's libraries in order for it to run properly when called under cron?
DEVELOPMENTS
I suspected that El Capitan Gatekeeper may have been the cause. So, I created a simplistic Objective C console application like so in a main.mm file and compiled.
#import <Foundation/Foundation.h>
int main(int argc, const char * argv[]) {
#autoreleasepool {
NSString *sTest = #"Hello World";
[sTest writeToFile:#"/tmp/test.txt" atomically:YES encoding:NSUTF8StringEncoding error:nil];
}
return 0;
}
Cron seems to run this just fine, so it's not looking like a Gatekeeper problem.
I got the problem to go away, but only briefly. I recompiled the project in a brand new project, copying over source code and settings. I then ran the command through the cron about 4 times without an issue. However, when I ran it the fifth time, it failed again and continued failing.
So, I guess I'm going to have to figure out how to convert this into a LaunchAgent.
The answer is YOU DON'T. You don't use cron anymore on OSX for your applications you are coding. Instead, switch to a LaunchAgent. Sure, Apple keeps it around for POSIX support, and therefore may keep it around for a very long time, but even their website encourages people to no longer use cron for application coding.
"Note: Although it is still supported, cron is not a recommended
solution. It has been deprecated in favor of launchd."
SOURCE: https://developer.apple.com/library/mac/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/ScheduledJobs.html
Unfortunately, though, LaunchAgents don't yet (in 10.11.4 at least) support cron-style syntax. (Yeah, I've already filed that suggestion to Apple for you.) So, there's no use of dash, comma, or backslash. Instead, it only supports an integer and multiple blocks to create each timeframe. And if that's not suitable enough, then set at least the most minimal timeframes and then do the rest of the code in whatever you are launching so that, for instance, if you want something only to run on the first Monday of the month, the LaunchDaemon launches in the first seven days but your application does a shutdown if it's not the first Monday of the month.
I'm trying to test the continuation facility in Pharo, with this code(in the playground):
| cont f |
f:=[
|i|
i:=0.
Continuation currentDo: [ :cc | cont:=cc ].
i:=i+1.
].
f value. "1"
cont. "a Continuation"
However, as soon as I call the continuation saved in cont(replacing cont. by cont value.), the image freezes immediately, and I have to press atl+. to gain back control.
VM version: VM: NBCoInterpreter NativeBoost-CogPlugin-GuillermoPolito.19 uuid: acc98e51-2fba-4841-a965-2975997bba66 May 15 2014 NBCogit NativeBoost-CogPlugin-GuillermoPolito.19 uuid: acc98e51-2fba-4841-a965-2975997bba66 May 15 2014 https://github.com/pharo-project/pharo-vm.git Commit: ed4a4f59208968a21d82fd2406f75c2c4de558b2 Date: 2014-05-15 18:23:04 +0200 By: Esteban Lorenzano <estebanlm#gmail.com> Jenkins build #14826
Pharo version: [version] 4.0 #40614
Thanks.
Edit: I was stupid, didn't think this through...
You've effectively created an infinite loop by reevaluating the same code again and again. You can see that if you debug the code and step through it. The original context will always be restored and then evaluated starting with the first expression following the #currentDo: send. This is exactly what the continuation is supposed to do: save the current position in the execution and restart there later on.
I do not have a Fedora to test, however I tried your code in Ubuntu, using this version of Pharo:
wget -O- get.pharo.org/40+vm | bash
./pharo-ui Pharo.image
and your code seems to work properly :(
In case this error persists, could you be more specific about the version of the vm you are using?:
./pharo Pharo.image --version
And the version of Pharo you are using?:
./pharo Pharo.image printVersion
Also, send us the crash.dmp file would help a lot.
Pig exists with exit code 7 after printing these 3 lines:
2014-07-16 21:57:37,271 [main] INFO org.apache.pig.Main - Apache Pig version 0.11.0-cdh4.6.0 (rexported) compiled Feb 26 2014, 03:01:22
2014-07-16 21:57:37,272 [main] INFO org.apache.pig.Main - Logging error messages to: ..../pig_1405562257268.log
2014-07-16 21:57:37,627 [main] INFO org.apache.pig.impl.util.Utils - Default bootup file /home/sam/.pigbootup not found
what does this mean?
The INFO messages are normal
The only unusual bit is the exit code (7, see above)
The pig_*.log file does not exist
Is this documented somewhere?
EDIT: the problem was eliminated when I removed the semicolon from the end of the %declare line.
go figure...
You may take a look at the return codes in the source code.
The book Programming Pig also contains a list of their meaning in chapter two.
I copy them here for reference:
0 Success
1 Retriable failure
2 Failure
3 Partial failure - Used with multiquery; see “Nonlinear Data Flows”
4 Illegal arguments passed to Pig
5 IOException thrown - Would usually be thrown by a UDF
6 PigException thrown - Usually means a Python UDF raised an exception
7 ParseException thrown (can happen after parsing if variable substitution
is being done)
8 Throwable thrown (an unexpected exception)
hi everybody sorry for my english level but i'm not english/american.
my question is the next: i try to use the example code that where posted in this site (How to get font color using pdfbox) in the example, the author says that the code was tried but when i tried it shows me this error:
jul 17, 2013 1:05:28 PM org.apache.pdfbox.util.PDFStreamEngine processOperator
INFO: unsupported/disabled operation: BDC
jul 17, 2013 1:05:29 PM org.apache.pdfbox.util.PDFStreamEngine processOperator
INFO: unsupported/disabled operation: EMC
DeviceGray
org.apache.pdfbox.pdmodel.graphics.color.PDColorState#481958
0.0
the pdf that i was extracting contents 3 letters (RGB) which is painted :
R: painted in red color
G: painted in green color
B: painted in black color
somebody can explain me because is this error o tell me how can i do to extract color text from a pdf?
thanks for all for the futures comments
Those log outputs are of level INFO only, not error:
jul 17, 2013 1:05:28 PM org.apache.pdfbox.util.PDFStreamEngine processOperator INFO: unsupported/disabled operation: BDC
jul 17, 2013 1:05:29 PM org.apache.pdfbox.util.PDFStreamEngine processOperator INFO: unsupported/disabled operation: EMC
All they say is that certain operators (BDC, EMC) were encountered in the page content for which no processor was registered. But as those operators are of interest for analyzing marked content only, those operators can be ignored for your task.
Thereafter you have output from the code you referred to:
DeviceGray
org.apache.pdfbox.pdmodel.graphics.color.PDColorState#481958
0.0
At least the first and the last line match that code: A color in DeviceGray gray with gray value 0 was encountered, most likely your black B. (Could it be you have added an additional output in-between, e.g. of graphicState.getStrokingColor()?)
Thus, no error, all working fine.