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

libswscale.so cause jvm crash #1055

Closed
jsjchai opened this issue Sep 2, 2018 · 15 comments
Closed

libswscale.so cause jvm crash #1055

jsjchai opened this issue Sep 2, 2018 · 15 comments
Labels

Comments

@jsjchai
Copy link

jsjchai commented Sep 2, 2018

Got a crash while working on javacv, couldn't dig out the cause so far, wondering if any life saver can help?

ffmpeg version : 3.4.1-1.4
Application scenario :Live streaming screenshot

A fatal error has been detected by the Java Runtime Environment:

SIGSEGV (0xb) at pc=0x00007f62f19abd45, pid=17119, tid=0x00007f636d8d4700

JRE version: Java(TM) SE Runtime Environment (8.0_144-b01) (build 1.8.0_144-b01)
Java VM: Java HotSpot(TM) 64-Bit Server VM (25.144-b01 mixed mode linux-amd64 compressed oops)
Problematic frame:
C [libswscale.so.4+0x6fd45]

Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again

If you would like to submit a bug report, please visit:
http://bugreport.java.com/bugreport/crash.jsp
The crash happened outside the Java Virtual Machine in native code.
See problematic frame for where to report the bug.

--------------- T H R E A D ---------------

Current thread (0x00007f6337fe7000): JavaThread "qtp425918570-17302" [_thread_in_native, id=25523, stack(0x00007f636d7d4000,0x00007f636d8d5000)]

siginfo: si_signo: 11 (SIGSEGV), si_code: 2 (SEGV_ACCERR), si_addr: 0x00007f60b7fc3000

Registers:
RAX=0x0000000000000146, RBX=0xffffffffffffffc4, RCX=0x0000000000000001, RDX=0x00007f636d8d2d00
RSP=0x00007f636d8d2bd8, RBP=0x00007f60b7d8c1c8, RSI=0x00007f636d8d2cd0, RDI=0x0000000000000000
R8 =0x00007f6338b4bb30, R9 =0x00007f636d8d2cb0, R10=0x00007f63380c1ac8, R11=0x0000000000000088
R12=0x00007f60b7fc3070, R13=0x00007f636d8d2ce0, R14=0x00007f636d8d2cd8, R15=0x00007f6309167f88
RIP=0x00007f62f19abd45, EFLAGS=0x0000000000010282, CSGSFS=0x0000000000000033, ERR=0x0000000000000004
TRAPNO=0x000000000000000e

@jsjchai jsjchai changed the title libswscale.so cause jvm crash libswscale.so cause jvm crash ["help wanted","question"] Sep 2, 2018
@jsjchai jsjchai changed the title libswscale.so cause jvm crash ["help wanted","question"] libswscale.so cause jvm crash new labels["help wanted","question"] Sep 2, 2018
@jsjchai jsjchai changed the title libswscale.so cause jvm crash new labels["help wanted","question"] libswscale.so cause jvm crash Sep 2, 2018
@jsjchai jsjchai changed the title libswscale.so cause jvm crash libswscale.so cause jvm crash Sep 2, 2018
@saudet
Copy link
Member

saudet commented Sep 3, 2018 via email

@jsjchai
Copy link
Author

jsjchai commented Sep 6, 2018

Javacv 1.4.2 also has this problem. This problem is accidental

@saudet
Copy link
Member

saudet commented Sep 6, 2018

Accidental, you mean that you cannot reproduce it consistently? It might be an issue with multithreading. Does it happen with only 1 thread?

@jsjchai
Copy link
Author

jsjchai commented Sep 6, 2018

Single thread is accidental. Multithreading must be present.How should I solve it?

@jsjchai
Copy link
Author

jsjchai commented Sep 6, 2018

Multi-threaded cause jvm crash is higher than single-threaded. But sometimes it is not jvm crash.

@saudet
Copy link
Member

saudet commented Sep 7, 2018

So, it's probably memory corruption occurring somewhere. Could you provide a code snippet to reproduce this issue?

@saudet
Copy link
Member

saudet commented Sep 15, 2018

Given the lack of feedback, I'm assuming you've been able to solve the issue, but please let me know if this isn't the case.

@saudet saudet closed this as completed Sep 15, 2018
@jsjchai
Copy link
Author

jsjchai commented Sep 15, 2018

sorry,I only see this reply now.

public class PullFlowCallable implements Callable<FFmpegFrameGrabber>{

    /**
     * Pull flow URL
     */
    private String url;
    /**
     * 
     */
    private String scoketId;
    
    public PullFlowCallable(String url,String scoketId) {
        super();
        this.url = url;
        this.scoketId = scoketId;
    }

    /**
     * @see Callable#call()
     */
    @Override
    public FFmpegFrameGrabber call() {
        FFmpegFrameGrabber grabber = null;
        try {
            grabber = FFmpegFrameGrabber.createDefault(url);
            grabber.setFormat("flv");
            grabber.setOption("probesize", "2048");
            grabber.setOption("max_analyze_duration", "11");
            grabber.start();
            return grabber;
        } catch (Exception e) {
            System.out.println("pull flow error,scoketId="+scoketId);
            try {
                grabber.close();
            } catch (Exception e1) {
             
            }
            return null;
        }
    }
    
}

Live streaming

package javacv;

import org.bytedeco.javacv.*;

import javax.imageio.ImageIO;
import java.awt.image.BufferedImage;
import java.io.File;
import java.io.IOException;
import java.util.concurrent.*;


public class LiveBroadcastTest {

    static Java2DFrameConverter converter = new Java2DFrameConverter();

    public static void main(String[] args) throws IOException {

        ExecutorService singleThread = Executors.newSingleThreadExecutor();

        //set Live stream URL
        Callable<FFmpegFrameGrabber> callable = new PullFlowCallable("", "test");
        Future<FFmpegFrameGrabber> future = singleThread.submit(callable);


        FFmpegFrameGrabber ff = null;
        try {
            ff = future.get(5L, TimeUnit.SECONDS);
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        } catch (ExecutionException e) {
            e.printStackTrace();
        } catch (TimeoutException e) {
            //Re-flow
            singleThread.shutdownNow();
            ExecutorService reSingleThread = Executors.newSingleThreadExecutor();
            Future<FFmpegFrameGrabber> reFuture = reSingleThread.submit(callable);
            try {
                ff = reFuture.get(10L, TimeUnit.SECONDS);
            } catch (InterruptedException e1) {
                Thread.currentThread().interrupt();
            } catch (ExecutionException e1) {
            } catch (TimeoutException e1) {
            } finally {
                reSingleThread.shutdown();
            }
        }
        if(ff != null){
            //save video img
            dealVideo(ff);
        }
    }


    private static void dealVideo(FFmpegFrameGrabber ff) throws IOException{
        ff.setFormat("flv");
        ff.start();
        int len = ff.getLengthInFrames();
        int i = 0;
        while (i < len){
            Frame image = ff.grabImage();
            if(image == null){
                continue;
            }
            System.out.println(i);
            BufferedImage bi = converter.getBufferedImage(image);
            ImageIO.write(bi, "png", new File("D:\\image\\" + i + ".png"));
            i++;
        }

        ff.close();
    }
}

@saudet
Copy link
Member

saudet commented Sep 15, 2018

When grabImage() returns null, we shouldn't be trying to call it again. Please try to replace continue with break this way:

            Frame image = ff.grabImage();
            if(image == null){
                break;
            }

@saudet
Copy link
Member

saudet commented Sep 15, 2018

Also I think it's calling start() twice, but we can't do that. Make sure it gets called only once.

@jsjchai
Copy link
Author

jsjchai commented Sep 15, 2018

The pull stream is called twice because the live stream is not pulled for the first time, and the stream is pulled down again.

@jsjchai
Copy link
Author

jsjchai commented Sep 15, 2018

Is this feasible?
Frame image = ff.grabImage(); if(image == null){ break; } if(image.image == null){ continue; }

@saudet
Copy link
Member

saudet commented Sep 15, 2018 via email

@jsjchai
Copy link
Author

jsjchai commented Sep 15, 2018

OK,thanks.

@saudet
Copy link
Member

saudet commented Sep 19, 2018

Have you been able to figure out if there is a bug in grabImage()? Like you said, it might be better to use grab()...

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

2 participants