text:
Exception while decompiling ... Decompiler process died

To Reproduce
Steps to reproduce the behavior:
./decomp_dbg
restore arm_npe.xml
lo fu _24_a

Expected behavior
A one to one exact replica of the original source code complete with original comments.
Attachments
arm_npe.xml
Environment (please complete the following information):

Ghidra Version: 3e245c6f80b1fe6465a8d5f73c09bcd1fd823fb1

Additional context
The cause of the crash

I was unable to reproduce this.  The decompiler console mode doesn't rebuild .sla files automatically.  Were your .sla files in sync with https://github.com/NationalSecurityAgency/ghidra/commit/3e245c6f80b1fe6465a8d5f73c09bcd1fd823fb1 ?

I was unable to reproduce this. The decompiler console mode doesn't rebuild .sla files automatically. Were your .sla files in sync with 3e245c6 ?

Oh this was totally my fault. It appears I had some uncommitted changes to the decompiler that I long forgot about that broke this.

authors: astrelsky caheckman

repo: NationalSecurityAgency/ghidra


text:
Decompiler misinterpreting x86 'switch' boundaries

Describe the bug
In the following assembly (from address 1008:151f onwards), there is a guard around the effective switch statement that ensures values outside the range 2 < AX <= 9 use the same branch as caseD_4:
   1008:1510 81 3e a2        CMP        word ptr [g_nUnreadSamplesInBuffer_24a2],498
             24 f2 01
   1008:1516 7d 07           JGE        LAB_1008_151f
   1008:1518 83 3e 72        CMP        word ptr [DAT_1030_0072],0x0
             00 00
   1008:151d 74 31           JZ         LAB_1008_1550
                             LAB_1008_151f                                   XREF[1]:     1008:1516(j)
   1008:151f c4 5e fa        LES        aBuffer,[BP + pwf]
   1008:1522 26 8a 07        MOV        AL,byte ptr ES:[aBuffer]
   1008:1525 98              CBW
   1008:1526 2d 02 00        SUB        AX,0x2
   1008:1529 8b d8           MOV        aBuffer,AX
   1008:152b 83 fb 07        CMP        aBuffer,0x7
   1008:152e 77 1a           JA         switchD_1008:1532::caseD_4
   1008:1530 03 db           ADD        aBuffer,aBuffer
                             switchD_1008:1532::switchD
   1008:1532 2e ff a7        JMP        word ptr CS:[aBuffer + 0x15f4]
             f4 15
                             switchD_1008:1532::caseD_3                      XREF[1]:     1008:1532(j)
                             switchD_1008:1532::caseD_5
                             switchD_1008:1532::caseD_9
                             switchD_1008:1532::caseD_2
   1008:1537 c7 06 72        MOV        word ptr [DAT_1030_0072],0x0
             00 00 00
   1008:153d c7 06 b0        MOV        word ptr [BOOL_1030_12b0],0x0
             12 00 00
   1008:1543 9a 80 17        CALLF      FUN_1010_1780                                    undefined2 FUN_1010_1780(void)
             10 10
   1008:1548 eb 06           JMP        LAB_1008_1550
                             switchD_1008:1532::caseD_6                      XREF[2]:     1008:152e(j), 1008:1532(j)
                             switchD_1008:1532::caseD_7
                             switchD_1008:1532::caseD_8
                             switchD_1008:1532::caseD_4
   1008:154a c7 06 72        MOV        word ptr [DAT_1030_0072],0x1
             00 01 00

However, in the decompilation the cases aren't setup at all and the 'guard' becomes an if (true).  Here's the decompilation:
   if ((497 < g_nUnreadSamplesInBuffer_24a2) || (DAT_1030_0072 != 0)) {
      if (true) {
         switch(*pwf) {
         default:
            DAT_1030_0072 = 0;
            BOOL_1030_12b0 = (0 | FALSE);
            FUN_1010_1780();
            goto LAB_1008_1550;
         }
      }
      DAT_1030_0072 = 1;
   }
LAB_1008_1550:
   if (DAT_1030_0072 == 0) {
.
.
.

Expected behavior
The output should recover the correct braches and guard condition given the accurate assembly.
Environment (please complete the following information):

OS: Windows 10
Java Version: 11.0.2
Ghidra Version: 10.1.4
Ghidra Origin: locally built

Additional context
Add any other context about the problem here.

It looks like Auto-Analysis recovered it properly. Not sure why follow-on decompilation isn't.
Can you post the output file from the  "Debug Function Decompilation" menu action for the function?  This action is in the menu accessible from the title bar of the Decompiler window.

Here's the current version:
dragmedi_FUN_1008_1434.zip
I hope this is enough to help.
If it does, a detailed explanation of the why's and wherefores would be really appreciated as I'm trying to deeply understand how Ghidra's internals work so that I can better assist...
Meanwhile, thanks for your time.

Thanks. I'm reproducing the switch problem now.

This was caused partly by switch analysis interacting with the "Eliminate unreachable code" option.  You had this toggled off which prevents any branches from getting removed.  In particular the conditional branch guarding the switch does not get removed like it ordinarily would be.  This is the cause of the "if (true)" syntax.  The presence of this extra branch prevents the control-flow around the indirect jump from being structured as a normal switch.   It would usually be structured as one case labeled "default", and 4 other case labels sharing a single destination/body.   The extra external branch into the switch prevents this definition from being interpreted as the "default", and instead it is interpreted as the switch exit.  This also causes the "goto" statement.
None of this is technically a bug but just awkward structuring forced by the analysis option.  However the decompiler should have enumerated the 4 case labels instead of using the "default" label. A switch where some values cause an immediate jump to the exit cannot also have a "default" case.

This was caused partly by switch analysis interacting with the "Eliminate unreachable code" option.

Thanks, that fixed this example.
I had removed that option thinking I'd ensure my output hadn't inadvertantly dropped something important!  In this regard, is there (or should there be) a way to get the switch analysis to ignore the "Eliminate unreachable code" option for its operation?

source: gharchive/issue

authors: Wall-AF caheckman

license_type: permissive

license_source: github-api


text:
Namespace not created in Symbol Tree

Describe the bug
When labeling a global data or function with a new namespace, the namespace is not added to the Symbol Tree.
Not 100% on repro yet, it's not happening for everything.
Working in a program called "foo"
Example class strings are like:  "foo::bar::baz::Thing1"
DTM would then be "foo/foo/bar/baz/Thing1" for the resulting class struct
"foo::bar::baz" namespace exists with class "Thing0"
If I label the vftable "foo::bar::baz::Thing1::vftable" it doesn't generate any new symbol tree entries for "Thing1" or "Thing1/vftable"
If I, from that vftable, label "foo::bar::baz::Thing1::FUN_aabbccdd", it is also not in the symbol tree anywhere, even though the decompiler/listing/Functions/Symbol Table windows all agree the namespace is there for the function
Exiting code browser does seem to trigger it to appear.
To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Attachments
If applicable, please attach any files that caused problems or log files generated by the software.
Environment (please complete the following information):

OS: win10
Java Version: 21.0.4
Ghidra Version: 11.2
Ghidra Origin: official GitHub distro

Additional context
Add any other context about the problem here.

Setting a label via the API and GUI text entry will not split-apart the namespace names.  This is because the ':' char is permitted in the name of a symbol.  Using the GUI, you would need to 1) create the appropriate namespace/class first, 2) create a label in the global namespace at the desired address, then 3) re-parent the symbol from the symbol tree.  I have never been a fan of this behavior.

It is a namespace.  Every window except symbol table agrees it's a namespace and treats it as such (ie namespace/name columns parse it, namespaced functions truncate symbol namespaces in decompiler).  Symbol table does after closing/reopening that window or codebrowser

Oh, I think you are right. I was confused by what ghidra1 said, which I believe is wrong also.

What should be working is updating labels via the Add Label or Edit Label... action in the Listing.  If you add namespace info, Ghidra will create it and the Symbol Tree should be updated.  For example, if you edit a label foo to be Parent::foo, Ghidra will create the namespace Parent, place foo in that namespace and the Symbol Tree will be updated to show Parent under the Namespaces node.  I just verified this is working for the happy path case I tried.

When labeling a global data or function with a new namespace, the namespace is not added to the Symbol Tree.

How are you creating your lablels?

Listing window, keyboard shortcut to label l.
Yeah, I'm not sure the reasoning why it takes a "refresh" of the symbol tree window for it to appear, but every other window seems happy.  Maybe it's a depth issue, my example names are changed but other similar structure.

authors: dragonmacher ghidra1 ghidragon mumbel


text:
Potential race condition when cleaning up skills-display component

If the client calls the SkillsDisplayJS.destroy() method before the PostMate.handshake() is called, the component will not get cleaned up and will persist in the browser, receiving events, attaching to the container and rendering, etc.  Need to capture when the destroy method is invoked before the child frame is attached, and then not initialize the skills-display if/when the handshake is eventually called.

:+1:

repo: NationalSecurityAgency/skills-client


text:
Negate siafund pool diff direction instead of hardcoding revert

From the lines above I think this was a typo. My understanding of consensus is lacking so I'm not sure what the impact of this bug was, if it even was a bug.

now the hard part. Can you write a test that failed before the change and succeeded after the change? That might be something that I need to do.
I'm thinking you'd create some reorg (using the _reorg.go file) that has a bunch of siafund pool diffs, and then you'd have some made up module that uses the diffs to keep track of the siafund pool size, and then you'd test that the siafund pool size according to the made up module matches the siafund pool size in the consensus set.

Actually, we might want to make a more broad test for the consensus change system that does that with all of the values. Again, that's probably more my responsibility than yours.

Even more, we should run that fake module in debug mode.

Closing this due to lack of bandwidth, can make an issue for more testing if you want, but I'm pretty confident at the moment that the code here is correct.

@DavidVorick we talked offline about how siafund pool diffs are different than other diffs. Can you explain this a bit more?

Most diffs indicate that you should either delete or create an object. So, in the usual case, when going forward you follow the instructions (create or delete), and when going backwards you follow the reverse of the instructions (delete or create).
In the case of the siafund pool, you are replacing the old siafund pool value with the new siafund pool value. I think that the way this is coded has the siafund pool diff always being added such that you should just apply it.
It's poorly commented code, I'm sorry about that. Actual testing will be needed to be certain that there is or is not a bug, and that testing should be added at some point soon.

source: gharchive/pull-request

authors: DavidVorick VoidingWarranties

repo: NebulousLabs/Sia

license: mit

license_source: bigquery


text:
Unbounded Currency

The Currency type can no longer overflow. However, its MarshalSia method restricts the length prefix to one byte, giving a maximum value of 2^(255 * 8) =~ 10^614. Larger values can be used internally, but will fail to encode correctly.
Also, Currency arithmetic will always return a new value. This means that you often have to write sum = sum.Add(value) instead of just sum.Add(value), but it isn't a big deal. Plus, you can chain operations now, and they're 10x more readable.
This change might have introduced some sneaky bugs. When I changed the return value from an error to a Currency, all the places where we had err = x.Add(y) threw compiler errors. But the places where we just had x.Add(y) were silent, so I had to hunt them all down manually. Hopefully I got them all.
Large-scale review of the consensus package is next.

it's impossible to encode negative numbers right?

Also, as we start to throw up more thorough testing, anywhere we wrote x.Add(y) should get caught

Can you add docstrings to all of the functions in currency.go?

Correct, negative Currency values cannot be encoded. They can, however, be created internally, since NewCurrency does not strip the sign information from the big.Int it is passed.

hm. That makes we wonder if there's anywhere we do subtraction that's vulnerable.

Sub is currently used in four places (and some commented-out tests):

In SplitContractPayout, to determine the output portion. The result is guaranteed to be non-negative.
In FundTransaction, to calculate the refund. After patching the bug in , the refund is also guaranteed to be non-negative.
In the weighted list code; I haven't rigorously verified that these are all okay, but they look fine.
In applySiafundInputs, to calculate the claim output. I don't know enough to verify this one; you should look it over.

I'm not as worried about the module code.
Also problematic: mul, div, and mulfloat could all take negative numbers. We also need to check that those values can't be manipulated to be negative inside of the consensus code.

for applySiafundInputs, claimStart is guaranteed to be less than or equal to s.siafundPool. This should actually be an if DEBUG { assert.

From a quick grepping, Mul, Div, and MulFloat are all safe; their arguments are always non-negative. But we'll definitely have to be careful about using them.

For the too long lines, it seems best to call NewCurrency in different lines, and then chain the muls. Just trying to keep things readable.

authors: DavidVorick lukechampine


text:
🛑 Becpl Angular UI is down

In baefe1d, Becpl Angular UI ($BECPL_ANGULAR_URL) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Becpl Angular UI is back up in 87fc00c after 17 minutes.

repo: NehalDamania/becpl-uptime

license: MIT


text:
🛑 Becpl Angular UI is down

In 1ac7d38, Becpl Angular UI ($BECPL_ANGULAR_URL) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Becpl Angular UI is back up in 4556c9e after 3 minutes.


text:
🛑 Becpl Angular UI is down

In fc9e0b9, Becpl Angular UI ($BECPL_ANGULAR_URL) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Becpl Angular UI is back up in 9a251f7 after 10 minutes.


text:
🛑 Becpl Angular UI is down

In 11fd211, Becpl Angular UI ($BECPL_ANGULAR_URL) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Becpl Angular UI is back up in f969e1f after 6 minutes.


text:
🛑 Becpl Angular UI is down

In c66ec26, Becpl Angular UI ($BECPL_ANGULAR_URL) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Becpl Angular UI is back up in 029fb71 after 5 minutes.


text:
🛑 Becpl is down

In d554ed1, Becpl ($BECPL_URL) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Becpl is back up in 9bfc7fc after 21 minutes.


text:
Local search as in minimap

If it is possible to do easily at all, would be great if local search will open like minimap on the right. With synced highlighting in the actual buffer.

I guess you want the search to open in a micro buffer pane (as a split) instead right?
I do plan to have a go at it but I will see how it goes.

authors: Bellavene Neko-Box-Coder

repo: Neko-Box-Coder/MicroOmni

license: Unlicense


text:
test: coverage for log limiting

Also updated to reset switches before each test and close the log popup after each test.
The "respects decorate switch" test assertion has been updated since graph is on by default, and the switches are now being reset before each test.
I should also mention I tried using tests.mocks.input instead of the <C-u> and such, but it didn’t seem to work, from what I could tell it was not clearing the existing value (default of 256 in this case).

Yea, tests.mocks.input is also a bit imperfect because it's prone to race conditions. When tests are run in parallel, they try to set the module values at the same time and... yeah, you get it, race condition 😓
Seems like, when possible, <c-u> is a better approach. However, I think it's also because the option value input doesn't use the input module: https://github.com/NeogitOrg/neogit/blob/f0bd7c736cc242258f0fdce0029f3b6331fe952b/lua/neogit/lib/popup/init.lua#L307-L311
So... That has something to do with it too.
Anyways, the PR is much appreciated :D

authors: CKolkey star-szr

repo: NeogitOrg/neogit


text:
Update ja.json

add DoNotSendReadStatus

Thank you for the update!

repo: Neos-Metaverse/NeosLocale


text:
Fix: undefined method `first' for nil:NilClass: app/views/searches/in…

A pull request to solve the issue https://github.com/Netflix/Scumblr/issues/81

Hi! I also ran into this issue and updated Scumblr on my machine to the latest commit on the master branch. I'm still running into the same undefined method `first' for nil:NilClass error. Any tips?

@gabbifish can you please past the entire log trace on http://pastebin.com/.

authors: fenicks gabbifish

repo: Netflix/Scumblr


text:
TaskDefinition validation error doesn't print actual value that is being validated

Describe the bug
TaskDefinition validation error doesn't print actual value that is being validated
Details

javax.validation.ConstraintViolationException: updateTaskDef.taskDefinition.retryCount: TaskDef retryCount: 10 must be <=10

2023-05-11 04:50:23.849 ERROR 25 --- [nio-8080-exec-9] c.n.c.r.c.ApplicationExceptionMapper     : Error ConstraintViolationException url: '/api/metadata/taskd
efs'

javax.validation.ConstraintViolationException: updateTaskDef.taskDefinition.retryCount: TaskDef retryCount: 10 must be <=10
        at org.springframework.validation.beanvalidation.MethodValidationInterceptor.invoke(MethodValidationInterceptor.java:120) ~[spring-context-5.3.19.jar!
/:5.3.19]
        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186) ~[spring-aop-5.3.19.jar!/:5.3.19]
        at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.proceed(CglibAopProxy.java:763) ~[spring-aop-5.3.19.jar!/:5.3.19]
        at org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:708) ~[spring-aop-5.3.19.jar!/:5.3.19]
        at com.netflix.conductor.service.MetadataServiceImpl$$EnhancerBySpringCGLIB$$d3d36b98.updateTaskDef(<generated>) ~[conductor-core-3.13.6.jar!/:3.13.6]
        at com.netflix.conductor.rest.controllers.MetadataResource.registerTaskDef(MetadataResource.java:104) ~[conductor-rest-3.13.6.jar!/:3.13.6]
        at jdk.internal.reflect.GeneratedMethodAccessor215.invoke(Unknown Source) ~[?:?]
        at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
        at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
        at org.springframework.web.method.support.InvocableHandlerMethod.doInvoke(InvocableHandlerMethod.java:205) ~[spring-web-5.3.19.jar!/:5.3.19]
        at org.springframework.web.method.support.InvocableHandlerMethod.invokeForRequest(InvocableHandlerMethod.java:150) ~[spring-web-5.3.19.jar!/:5.3.19]
        at org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:117) ~[sprin
g-webmvc-5.3.19.jar!/:5.3.19]

This is coming from
https://github.com/Netflix/conductor/blob/5bcd22abfc9b8c1fc055d00721490dd04492cb00/common/src/main/java/com/netflix/conductor/common/metadata/tasks/TaskDef.java#L66
@ProtoField(id = 3)
@Min(value = 0, message = "TaskDef retryCount: {value} must be >= 0")
@Max(value = 10, message = "TaskDef retryCount: {value} must be <=10")
private int retryCount = 3; // Default
Conductor version: 3.13.6
Persistence implementation: Dynomite
Queue implementation: Dynoqueues
Lock: noop_lock
Workflow definition: NA
Task definition: NA
Event handler definition: NA
To Reproduce
Expected behavior
Error should print both max value and value that is being validated. Something like

javax.validation.ConstraintViolationException: updateTaskDef.taskDefinition.retryCount: TaskDef retryCount: 12 must be <= 10

Screenshots
If applicable, add screenshots to help explain your problem.
Additional context
Add any other context about the problem here.

Hi @charybr , can you please close this issue since the changes are merged?

sure, thanks very much!

repo: Netflix/conductor


text:
HTTP Task of type POST doesn't get body from request

Hi,
I created a simple HTTP Task of type POST which passes the workflow's input as the body param.
When I trigger the workflow, Conductor does call the endpoint, but it doesn't pass the body.
I suspect that this is a bug, but if not I would appreciate your help understanding what am I missing.
In the conductor UI, I can see that the Task input looks good:
{
  "http_request": {
    "uri": "http://localhost:4800/date-to-year",
    "method": "POST",
    "contentType": "application/json",
    "body": {
      "date": "1800-01-01"
    }
  }
}

workflow definition:
{
  "name": "liran-date-to-year-rest-post",
  "description": "Gets date and returns year from it",
  "tasks": [
	{
      "name": "liran-task",
      "taskReferenceName": "liran-task",
      "inputParameters": {
		  "http_request": {
		    "uri": "http://localhost:4800/date-to-year",
		    "method": "POST",
    		"contentType": "application/json",
    		"body": "${workflow.input}"
		  }
      },
      "type": "HTTP"
	}
  ],
  "outputParameters": {
    "finalYear": "${liran-task.output.response.body.year}"
  },
  "schemaVersion": 2
}

execution example:
curl -X POST
http://localhost:8080/api/workflow/liran-date-to-year-rest-post
-H 'Content-Type: application/json'
-d '{"date": "1800-01-01"}'
I also tried to define the workflow with constant body
"inputParameters": {
  "http_request": {
    "uri": "http://localhost:4800/date-to-year",
    "method": "POST",
	"contentType": "application/json",
	"body": {"date": "2000-01-01"}
  }

just for the test to see if my endpoint gets the body.. but still it didn't
thank you!

Can you let me know where did you configure  your workflow definition, so that the conductor server will instantiate?

Sorry, I didn't understand your question.. What do you mean by "where"?
On Sat, Aug 4, 2018, 20:01 dileepkeely notifications@github.com wrote:

Can you let me know where did you configure your workflow definition, so
that the conductor server will instantiate?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Netflix/conductor/issues/673#issuecomment-410463174,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACx0Kg8kGBBJ5T-3ca-D9KvqeSa7WzN8ks5uNdOCgaJpZM4Vaesj
.

--
Sent from my phone

I think I am facing this issue as well, any help is much appreciated.

I am facing same issue in v2.25.9, any suggestion would be great.

authors: LiranBri SanjayaKumarSahoo dileepkeely eklavya