Binary Domain Activation Code [cheat]
Outi Foote
I'm having trouble trying to profile a binary application that needs to be run in a new linux terminal window using VTune. It needs to launch in a terminal because I need to interact with it after startup. For reference, I'll call this binary myAPP.
I tried launching myAPP directly from within the vtune-gui using launch-application, where the myAPP output gets redirected to the terminal that was used to launch vtune-gui. The problem with this is that while the myAPP print output displays in this terminal, it doesn't respond to the Ctrl-C we trap in myAPP, which allows myAPP to drop into its internal console command prompt and accept user input.
I've also tried launching myAPP by wrapping it in a shell script, and using gnome-terminal to run myAPP in a new terminal window. This works fine for allowing me to interact with myAPP, but for some reason VTune doesn't seem to be able to profile the myAPP process when launched this way.
I've checked the box for Analyze child processes, and even tried selecting Analyze system-wide, and tried using Auto, Native, and Mixed managed code profiling modes, but VTune still doesn't appear to detect and profile it. The script I use to launch myAPP in a new terminal window using gnome-terminal is as follows:
So, since you won't be able to test the Ctrl-C trapping that myAPP does, maybe we could focus instead on the fact that when I run myAPP in a new terminal window using gnome-terminal (see previous post for shell script example), VTune doesn't seem to be able to detect and analyze the myAPP process that gnome-terminal launched.
In this original post, I simplified the shell script example I included for describing this problem. In the real shell script, I'm launching several other applications along with the gnome-terminal -- ./myAPP command (see below). All of these applications are part of a single integrated system, and my goal is to be able to analyze the entire system all at once across multiple runs.
Can the vtune command line handle launching all of these applications together? If so, then I can launch the myAPP program without using the gnome terminal, and my problem would be solved. If not, then I still don't have a solution.
Intel does not verify all solutions, including but not limited to any file transfers that may appear in this community. Accordingly, Intel disclaims all express and implied warranties, including without limitation, the implied warranties of merchantability, fitness for a particular purpose, and non-infringement, as well as any warranty arising from course of performance, course of dealing, or usage in trade.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Then, you can open the app file normally, but it will fail because gatekeeper won't be able to verify the file. From there, go into your "Security and Privacy" in "System Preferences" and then click to allow the app to open.
I had this issue with a universal binary (Terminal) that I duplicated and explicitly set in the info "Open using Rosetta" to run x86 tools like Homebrew. After updating to 11.0.1 from 11.0.0, the x86 version of the terminal stopped working with the above error.
Once I fixed the .gitattributes file to only use LF with p-list files, I built a new app and had it codesigned and it worked--no aborts. I also had to make sure Jenkins wiped the workspace since it didn't seem to fix the file at first.
I encountered this issue when sending to a colleague for testing a Mac app that I developed. He tried some of the suggestions on this forum, but they didn't seem to work (and we're both on Intel, so the Rosetta tips didn't apply).
What ultimately worked for me was creating a blank disk image, and then adding the .app file to the image and then sending him the disk image. It seems like the problem comes up when the .app file is compressed, and adding the file to a disk image first seems to help prevent the issue.
The Cadence CLI is a command-line tool you can use to perform various tasks on a Cadence server. It can performdomain operations such as register, update, and describe as well as workflow operations like startworkflow, show workflow history, and signal workflow.
For example docker run --rm ubercadence/cli:0.21.3 --domain samples-domain domain describe will be the CLI that is released as part of the v0.21.3 release (opens new window).See docker hub page (opens new window) for all the CLI image tags.Note that CLI versions of 0.20.0 works for all server versions of 0.12 to 0.19 as well. That's because the CLI version doesn't change in those versions (opens new window).
NOTE: On Docker versions 18.03 and later, you may get a "connection refused" error when connecting to local server. You can work around this by setting the host to "host.docker.internal" (see here (opens new window) for more info).
To build the CLI tool locally, clone the Cadence server repo (opens new window), check out the version tag (e.g. git checkout v0.21.3) and runmake tools. This produces an executable called cadence. With a local build, the same command todescribe a domain would look like this:
Run cadence for help on top level commands and global optionsRun cadence domain for help on domain operationsRun cadence workflow for help on workflow operationsRun cadence tasklist for help on tasklist operations(cadence help, cadence help [domainworkflow] will also print help messages)
Use option --workflowidreusepolicy or --wrp to configure the workflow ID reuse policy.Option 0 AllowDuplicateFailedOnly: Allow starting a workflow execution using the same workflow ID when a workflow with the same workflow ID is not already running and the last execution close state is one of [terminated, cancelled, timedout, failed].Option 1 AllowDuplicate: Allow starting a workflow execution using the same workflow ID when a workflow with the same workflow ID is not already running.Option 2 RejectDuplicate: Do not allow starting a workflow execution using the same workflow ID as a previous workflow.
Terminating a running workflow execution will record a WorkflowExecutionTerminated event as the closing event in the history. No more decision tasks will be scheduled for a terminated workflow execution.Canceling a running workflow execution will record a WorkflowExecutionCancelRequested event in the history, and a new decision task will be scheduled. The workflow has a chance to do some clean up work after cancellation.
Batch job is based on List Workflow Query(--query). It supports signal, cancel and terminate as batch job type.For terminating workflows as batch job, it will terminte the children recursively.
If a bad deployment lets a workflow run into a wrong state, you might want to reset the workflow to the point that the bad deployment started to run. But usually it is not easy to find out all the workflows impacted, and every reset point for each workflow. In this case, auto-reset will automatically reset all the workflows given a bad deployment identifier.
Let's get familiar with some concepts. Each deployment will have an identifier, we call it "Binary Checksum" as it is usually generated by the md5sum of a binary file. For a workflow, each binary checksum will be associated with an auto-reset point, which contains a runID, an eventID, and the created_time that binary/deployment made the first decision for the workflow.
To find out which binary checksum of the bad deployment to reset, you should be aware of at least one workflow running into a bad state. Use the describe command with --reset_points_only option to show all the reset points:
Then use this command to tell Cadence to auto-reset all workflows impacted by the bad deployment. The command will store the bad binary checksum into domain info and trigger a process to reset all your workflows.
As you add the bad binary checksum to your domain, Cadence will not dispatch any decision tasks to the bad binary. So make sure that you have rolled back to a good deployment(or roll out new bits with bug fixes). Otherwise your workflow can't make any progress after auto-reset.
I work with multiple servers with various architectures (e.g., Intel, AMD, Arm, etc.) when I'm testing software on Linux. Once I've provisioned a Linux box and the server meets my testing needs, I still have a number of steps to do:
I've wanted to learn Golang for a while, and converting my beloved shell script into a Go program seemed like a good project to help me get started. The syntax seemed fairly simple, and after trying out some test programs, I set out to advance my knowledge and become familiar with the Go standard library.
I continued relying on my shell script until I finished the Go program. Then I pushed the binary onto a central file server so that every time I provisioned a new server, all I had to do was wget the binary, set the executable bit on, and run the binary. I was happy with the early results:
What happened? I didn't make any changes to the source code, the compilation threw no errors nor warnings, and it worked well the last time I ran it, so I looked more closely at the error message, format error.
I quickly ran the following command to identify the architecture of the test server I provisioned and where the binary was trying to run. It was Arm64 architecture, but the binary I compiled (on my x86 laptop) was generating an x86-64 format binary:
Until then, I had never accounted for this scenario (although I knew about it). I primarily work on scripting languages (usually Python) coupled with shell scripting. The Bash shell and the Python interpreter are available on most Linux servers of any architecture. Hence, everything had worked well before.
7fc3f7cf58