Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Geth console, panic at setInterval / setTimeout etc.. #1082

Closed
holiman opened this issue May 23, 2015 · 7 comments
Closed

Geth console, panic at setInterval / setTimeout etc.. #1082

holiman opened this issue May 23, 2015 · 7 comments
Assignees
Labels
Milestone

Comments

@holiman
Copy link
Contributor

holiman commented May 23, 2015

Panic crash with setInterval with invalid parameters:

> setInterval()
panic: runtime error: index out of range

goroutine 119 [running]:
github.com/ethereum/go-ethereum/jsre.(*JSRE).runEventLoop(0xc2081d1240)
    /build/ethereum-JpVrVd/ethereum-0.9.23+23trusty/obj-x86_64-linux-gnu/src/github.com/ethereum/go-ethereum/jsre/jsre.go:168 +0xb8c
created by github.com/ethereum/go-ethereum/jsre.New
    /build/ethereum-JpVrVd/ethereum-0.9.23+23trusty/obj-x86_64-linux-gnu/src/github.com/ethereum/go-ethereum/jsre/jsre.go:65 +0x280

goroutine 1 [runnable]:

Relevant code jsre/jsre.go:

func (self *JSRE) runEventLoop() {
    registry := map[*jsTimer]*jsTimer{}
    ready := make(chan *jsTimer)

    newTimer := func(call otto.FunctionCall, interval bool) (*jsTimer, otto.Value) {

        delay, _ := call.Argument(1).ToInteger()
        if 0 >= delay {
            delay = 1
        }
        timer := &jsTimer{
            duration: time.Duration(delay) * time.Millisecond,
            call:     call,
            interval: interval,
        }
        registry[timer] = timer

        timer.timer = time.AfterFunc(timer.duration, func() {
            ready <- timer
        })

        value, err := call.Otto.ToValue(timer)
        if err != nil {
            panic(err)
        }

        return timer, value
    }

    setTimeout := func(call otto.FunctionCall) otto.Value {
        _, value := newTimer(call, false)
        return value
    }

    setInterval := func(call otto.FunctionCall) otto.Value {
        _, value := newTimer(call, true)
        return value
    }

    clearTimeout := func(call otto.FunctionCall) otto.Value {
        timer, _ := call.Argument(0).Export()
        if timer, ok := timer.(*jsTimer); ok {
            timer.timer.Stop()
            delete(registry, timer)
        }
        return otto.UndefinedValue()
    }
    self.vm.Set("setTimeout", setTimeout)
    self.vm.Set("setInterval", setInterval)
    self.vm.Set("clearTimeout", clearTimeout)
    self.vm.Set("clearInterval", clearTimeout)

Specifically:

        if err != nil {
            panic(err)
        }

Panic crash? Seems a bit drastic... I'd submit a patch, but the panic looks pretty intentional.

@zelig
Copy link
Contributor

zelig commented May 24, 2015

thanks for tracking it down, will look into it

@zelig
Copy link
Contributor

zelig commented Jun 1, 2015

fixed in #1090

@zelig zelig closed this as completed Jun 1, 2015
@fjl
Copy link
Contributor

fjl commented Jun 1, 2015

It has not been fixed yet. I'll close the issue when it is fixed.

@fjl fjl reopened this Jun 1, 2015
@zelig
Copy link
Contributor

zelig commented Jun 1, 2015

cool cool, how about #1083? cos I just believed you in #1090 (merged) you said both #1082 and #1083 were fixed ;) so I closed that too

@DennisBPeterson
Copy link

I got an index out of range with the stack trace starting at goroutine 22318, is that the same issue? This is during initial blockchain sync. It generally crashes within a few minutes, maybe half an hour on the outside.

@holiman
Copy link
Contributor Author

holiman commented Jun 2, 2015

@DennisBPeterson no, it's not related, so you better file a new issue about it. When you do, don't forget to post the stack trace from the dump, ~10-20 lines is often enough. And before you do, please ensure that you're running a fairly recent build.

@zelig
Copy link
Contributor

zelig commented Aug 24, 2015

@fjl status on this?

karalabe added a commit to karalabe/go-ethereum that referenced this issue Nov 23, 2015
@obscuren obscuren assigned karalabe and unassigned fjl Nov 23, 2015
obscuren added a commit that referenced this issue Nov 26, 2015
jrse: fix #1082, fail if setTimeout/setInterval lack callback
@fjl fjl added this to the 1.4.0 milestone Jan 8, 2016
@obscuren obscuren changed the title Geth console, panic at setInterval / setTimeout etc.. Geth console, panic at setInterval / setTimeout etc.. Feb 16, 2016
tony-ricciardi pushed a commit to tony-ricciardi/go-ethereum that referenced this issue Jan 20, 2022
* metrics: disable CPU stats (gosigar) on iOS

* Remove gosigar override from go.mod

Co-authored-by: Péter Szilágyi <peterke@gmail.com>
tony-ricciardi pushed a commit to tony-ricciardi/go-ethereum that referenced this issue Jan 20, 2022
### Description

This PR includes the necessary bits to setup a CI pipeline that cross-compiles all geth tools into release binaries for the platforms we want/support. Currently these are:

- ✅Linux 32bit/64bit
- ✅Darwin 32bit/64bit (~pending on ethereum#1082~ merged!)
- ✅Windows 64bit (~pending on celo-bls-go v0.1.6 release~ ~pending on ethereum#1089~ merged!)

Elements of the PR:

- `Dockerfile.binaries` for the container where cross-compilation occurs. It's based on a [fork of xgo](https://github.com/techknowlogick/xgo), and includes some back-ported mingw packages for the windows build.


- Changes to the `geth` build scripts:
   - Introduce a new CI environment in `internal/build/env.go` which which can be used for Google Cloud Build.
   - Create a new ci task in `build/ci.go` that bundles the binaries into well named release archive


- `cloudbuild-binaries.yaml` which defines the CI pipeline. It should be used in conjunction with a trigger on `release/.*` and `master` branches and the trigger should have to variables:
  - `_BUCKET` with the name of the google cloud storage bucket where the artefacts will be stored
  - `_BUILD_TARGETS` comma-separated string of build targets. e.g. `linux/amd64,linux/386`

#### Shortcomings 

- 🔴 The geth `build.Environment` struct requires the commit timestamp, which is then passed to `main.gitDate` in the binaries that it builds. Usually this is extracted from the git but in Cloud Build in the CI steps the git data is stripped and all we have is what's passed through env vars. I have substituted the commit timestamp with the build timestamp instead.
- 🟡 The `xgo` image is really large (3gb) and adds about ~4minutes to the build time

#### Release artefacts

The pipeline outputs release artefacts into `<bucket>/<branch>/<file>`. For example here's the output of a test build:

<img width="553" alt="Screenshot 2020-06-29 at 11 41 00" src="https://user-images.githubusercontent.com/304771/85994959-1433eb00-b9fe-11ea-9180-22ea95cb774c.png">

A few things to notice here:

- The folder is `<bucket>/release/1.1` yet the version is `1.0.0-unstable` this is because there isn't any enforced relationship between the branch name and the version sourced from `params/version.go` which is the authoritative source. So in this case I just created the dummy `release/1.1` branch on my fork in order to play around. Because we're using the branch name in the path all "nightly" version will be stored in the `<bucket>/master` folder, if we setup the trigger on `master`.

- There are 2 archives per platform, one containing only `geth` and the other containing all binary tools located inside `cmd`, just like geth releases. ⚠️ The archives also contain the "COPYING" file, we need to decide if we want to make changes to that ⚠️
 

#### Post-merge TODOs:

- [x] Create a bucket and triggers in `celo-testnet` to start running the pipeline
- [x] Enable more build targets as they are unblocked 
 
### Tested

I have currently tested the CI pipeline in a personal google cloud project and tested the linux binaries in docker.

### Related issues

- Fixes ethereum#1073 

### Backwards compatibility

Changes are only related to tooling so no problem with compatibility.
maoueh pushed a commit to streamingfast/go-ethereum that referenced this issue Nov 29, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants