"panic: runtime error: invalid memory address or nil pointer dereference" when running "jfrog rt npmp"
Describe the bug When running jfrog rt npmp --build-name={} --build-number={} , I get the following (similar to #1297 )
[Info] Running npm Publish
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x8 pc=0xb9f71e]
goroutine 1 [running]:
github.com/jfrog/jfrog-cli-core/v2/artifactory/commands/npm.(*NpmPublishCommand).preparePrerequisites(0xc00023d600)
/root/go/pkg/mod/github.com/jfrog/jfrog-cli-core/[email protected]/artifactory/commands/npm/publish.go:192 +0xfe
github.com/jfrog/jfrog-cli-core/v2/artifactory/commands/npm.(*NpmPublishCommand).Run(0xc00023d600)
/root/go/pkg/mod/github.com/jfrog/jfrog-cli-core/[email protected]/artifactory/commands/npm/publish.go:138 +0x77
github.com/jfrog/jfrog-cli-core/v2/common/commands.Exec({0xf192e0, 0xc00023d600})
/root/go/pkg/mod/github.com/jfrog/jfrog-cli-core/[email protected]/common/commands/command.go:26 +0xad
github.com/jfrog/jfrog-cli/artifactory.npmPublishCmd(0xc0000d2f20)
/var/jenkins_home/workspace/eco-system/release/jfrog-cli-release/temp/jfrog-cli/artifactory/cli.go:1197 +0x1cf
github.com/jfrog/jfrog-cli/artifactory.GetCommands.func33(0x1)
/var/jenkins_home/workspace/eco-system/release/jfrog-cli-release/temp/jfrog-cli/artifactory/cli.go:537 +0x19
github.com/codegangsta/cli.HandleAction({0xc8cdc0, 0xe06e28}, 0xb)
/root/go/pkg/mod/github.com/codegangsta/[email protected]/app.go:490 +0x5a
github.com/codegangsta/cli.Command.Run({{0xdbcd6a, 0xb}, {0x0, 0x0}, {0xc00023a770, 0x1, 0x1}, {0x0, 0x0}, {0x0, ...}, ...}, ...)
/root/go/pkg/mod/github.com/codegangsta/[email protected]/command.go:210 +0x8f8
github.com/codegangsta/cli.(*App).RunAsSubcommand(0xc000222680, 0xc0000d2c60)
/root/go/pkg/mod/github.com/codegangsta/[email protected]/app.go:379 +0x985
github.com/codegangsta/cli.Command.startApp({{0xdb6baa, 0x2}, {0x0, 0x0}, {0x0, 0x0, 0x0}, {0x0, 0x0}, {0x0, ...}, ...}, ...)
/root/go/pkg/mod/github.com/codegangsta/[email protected]/command.go:298 +0x6bb
github.com/codegangsta/cli.Command.Run({{0xdb6baa, 0x2}, {0x0, 0x0}, {0x0, 0x0, 0x0}, {0x0, 0x0}, {0x0, ...}, ...}, ...)
/root/go/pkg/mod/github.com/codegangsta/[email protected]/command.go:98 +0x418
github.com/codegangsta/cli.(*App).Run(0xc0002224e0, {0xc0000300a0, 0x5, 0x5})
/root/go/pkg/mod/github.com/codegangsta/[email protected]/app.go:255 +0x6ac
main.execMain()
To Reproduce After I've upgraded the jFrog cli version to 2.6.1 the command fails with the above error, works fine with v2.5.1 version of cli.
Expected behavior Publishing npm package should not throw an error.
Screenshots If applicable, add screenshots to help explain your problem.
Versions
- JFrog CLI version: 2.6.1
- JFrog CLI operating system: Alpine Linux v3.11
- Artifactory Version: 7.24.4
Additional context As a temporary fix, I have rolled back the cli version to 2.5.1 and it works as expected.
Hi @SomaSharath , Thank you for reporting this issue. We just released version 2.6.2 that includes a fix. We'd appreciate your feedback for it.
Hi. The related issue https://github.com/jfrog/jfrog-cli/issues/1297 mentionned is not fixed by version 2.6.2
Seeing this issue in 2.71.5 looks like it's been open for 3 years, so I'm assuming theres no hope of a fix from jfrog
We were having the same issue and paniced ourselves just like the go panic.
We used "--detailed-summary" with the publish command( jf npm publish "--detailed-summary" ).
This stopped the panic: runtime error: invalid memory address or nil pointer.
Once the error was gone, identified issue with package.json/run that was caused by lack of git in the docker environment where we were building this. Fixing that root issue resolved the npm publish issue for us.
The memory panic error isnt useful, it should be handled in the jf cli code. As one of our lead developer says somewhere over here.. https://github.com/jfrog/jfrog-client-go/blob/40364ef34208461eba50c4d2eb878d726bb1df54/artifactory/services/utils/resultutils.go#L87
This issue has been marked as stale due to 6 months of inactivity. As part of our effort to address every issue properly, please feel free to remove the stale label or keep this issue active by leaving a comment. Otherwise, it will be closed in 7 days
This issue was closed due to 7 days of inactivity after being marked as stale. Feel free to reopen it if it remains relevant.