Question about JVM Crashed in Using rtspsrc and splitmuxsink

[BK Huang]

Hello all,

I am trying to record the RTSP streams and store them in files, so I used rtspsrc and splitmuxsink.

I found that JVM crashed after running for about 10 minutes when using gst1-core-java 1.14, but it worked well when trying gst1-core-java 1.13.

The console log showed different reasons for JVM crashed, for example:

• free(): invalid size
• free(): invalid pointer
• free(): double free detected in tcache 2
• munmap_chunk(): invalid pointer
• malloc_consolidate(): invalid chunk size
• malloc_consolidate(): unaligned fastbin chunk detected
• malloc(): unaligned tcache chunk detected
• double free or corruption (out)
• double free or corruption (fasttop)

Would anyone helps to check is there any wrong usage of my code or is it a potential issue of gst1-core-java 1.14?

Thank you very much.

To reproduce the problem easily, a simpler version of the codes and some details are listed below.

• OS: Linux
• Java version: OpenJDK 16.0.1
• GStreamer version: 1.18.4
• Gst1-java-core version: 1.14
• Sample: https://dsfv4oaioosvz.cloudfront.net/sample.java

----

Best wishes,

BK Huang

[Neil C Smith]

Hi,

On Mon, 5 Jul 2021 at 11:43, BK Huang <light...@gmail.com> wrote:
> Would anyone helps to check is there any wrong usage of my code or is it a potential issue of gst1-core-java 1.14?

The obvious problem in the sample code is that you're not keeping the
Pipeline reference in a static field, so it is likely to be garbage
collected and crash.

It's possible that the previous message handling in 1.3 was keeping
the Pipeline reference alive long enough in your case so you didn't
notice this bug in your code there.

A reference to the top-level Pipeline must be kept alive (ie. not
local). Listener and child element references will be kept alive via
the pipeline reference.

Best wishes,

Neil

--
Neil C Smith
Codelerity Ltd.
www.codelerity.com

Codelerity Ltd. is a company registered in England and Wales
Registered company number : 12063669
Registered office address : Office 4 219 Kensington High Street,
Kensington, London, England, W8 6BD

[Bo-Kai Huang]

Hi Neil,

I also tried to put Pipeline as a private static field at the beginning of this class, but results are the same.

The sample: https://dsfv4oaioosvz.cloudfront.net/sample2.java

Would you help check it?

Thank you.

---

Best regards,

BK Huang

--
You received this message because you are subscribed to the Google Groups "gstreamer-java" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gstreamer-jav...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gstreamer-java/CAPxOS5FrFq59sZHOnd0zg8NazUyjXpccV6%3DQyvwhtHqcgmy%3DCg%40mail.gmail.com.

[Neil C Smith]

On Mon, 5 Jul 2021, 13:18 Bo-Kai Huang, <light...@gmail.com> wrote:

I also tried to put Pipeline as a private static field at the beginning of this class, but results are the same.

The sample: https://dsfv4oaioosvz.cloudfront.net/sample2.java

Would you help check it?

I will see if I can replicate, but won't be until next week. 

I realised after posting that the fact you call pipeline.stop() after Gst.main() may be protecting you from this common issue.

The issue you see suggests something is being garbage collected before it should. Try strong (static) references for the elements you add listeners to, as well as your custom callback implementation.

Best wishes, 

Neil

[Bo-Kai Huang]

Hi Neil,

Thanks for your help.

If you need any information about my environment or anything I didn't describe properly, please let me know at anytime.

Just an update: I did try static references for callbacks and elements in callbacks, the issue still happened.

----

Best Regards,

BK Huang

--

You received this message because you are subscribed to the Google Groups "gstreamer-java" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gstreamer-jav...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/gstreamer-java/CAPxOS5Gm0mBHGNWjXHF7KugnR6p1GPF1%2BLBToWhgtzOMJEFgHg%40mail.gmail.com.

[Bo-Kai Huang]

Hi Neil,

I think I find the problem.

As you mentioned, it is not related to 1.4.0. The problem also happened even by using 1.3.0.

The root cause is that the callback of signal expects a pointer of gchararray, but in the sample returned a String.

Now the JVM runs normally after fixing it.

I really appreciate your help.

----

Best Regards,

BK Huang

 

[Tiago Frazao]

@Bo-Kai Huang,

  Could you share your Callback implementation ? 
  I have the same issue and I have no access to your sample (https://dsfv4oaioosvz.cloudfront.net/sample.java)

@Everyone,

I am trying to split the files based in timestamp instead of fragment ids.

So, I created a callback to replace the format-location-full with the desired file name.

I have noticed that this callback is called only once (fragment id 0) and later it use the standard location defined in the pipeline
(I have no idea why it does not call this callback before creating new spllited file)

   /tmp/20231219-101824.mkv
   /tmp/monitr-0000000001.mkv
   /tmp/monitr-0000000002.mkv
   ...

• OS: Ubuntu 23.10
• Java version: Ppenjdk 17.0.9 2023-10-17
• GStreamer version: 1.22.5
• Gst1-java-core version: 1.4.0

PIPELINE  EXPRESSION :

  pulsesrc name=audioSource device=alsa_input.usb-GHW_Micro_GHW_USB_AUDIO_2020-02-20-0000-0000-0000--00.mono-fallback

! queue silent=true ! audioconvert ! identity name=audio-identity ! tee name=aud

aud. ! queue silent=true ! lamemp3enc ! tee name=aud1

aud1. ! queue silent=true ! mux02.audio_0

aud. ! queue silent=true ! wavescope style=lines

! textoverlay name=text-message valignment=center halignment=center font-desc='Ubuntu, 30' xpad=0 ypad=0

! textoverlay name=text-activity valignment=bottom halignment=left font-desc='Ubuntu, 20' xpad=0 ypad=0 shaded-background=true

! textoverlay name=text-geek valignment=top halignment=right color=0xFFFFFF00 font-desc='Ubuntu, 9' xpad=0 ypad=0 shaded-background=true

! queue silent=true ! appsink name=video-sink emit-signals=true drop=true sync=true

aud. ! queue silent=true ! audioresample ! audio/x-raw, rate=48000, format=S16LE, channels=2 ! level name=audiolevel ! pulsesink name=audio-sink sync=true

splitmuxsink name=mux02 location=/tmp/monitr-%010d.mkv max-size-time=10000000000 muxer-factory=matroskamux

CALLBACK CONNECTION :

Element mux02 = pipeline.getElementByName("mux02");

mux02.connect(ISplitMux.FORMAT_LOCATION_SIGNAL, ISplitMux.class, splitMuxDateFormat, ISplitMux.format_location_full_callback(splitMuxDateFormat));

public interface ISplitMux extends GstCallback {

public static final String FORMAT_LOCATION_SIGNAL = "format-location-full";

// I have also tried format-location signal but I get the same issue.

public String format_location_full_callback(Bin element, int fragmentId);

public static GstCallback format_location_full_callback(ISplitMux listener) {

return new GstCallback() {

@SuppressWarnings("unused")

public String callback(Bin elem, int fragmentId) {

return listener.format_location_full_callback(elem, fragmentId);

}

};

}

}

FORMAT_LOCATION_CALLBACK IMPL:

public class SplitMuxDateFormat implements ISplitMux {

@Override

public String format_location_full_callback(Bin element, int fragmentId) {

return String.format("/tmp/%s.%s", DateUtils.formatDate(DateUtils.YYYYMMDD_HHMMSS, DateUtils.getCurrentDate()), "mkv");

}

}

Best Regards
Tiago F. Frazao

[Tiago Frazao]

H Everyone,

Just to et you know.

I have solved the issue about "splitmux signal that creates the correct filename only for the first fragment".

Basically I have to remove all close invokes of GST Objects (try (....) resources). (I had other listeners that where closing objects using java try resources and this method)
As I could see, this closable method removes all signal event from the pipeline causing the issue.

Best Regards
Tiago F. Frazao

[Neil C Smith]

On Thu, 28 Dec 2023 at 11:40, Tiago Frazao <tiago....@gmail.com> wrote:
> Just to et you know.
> I have solved the issue about "splitmux signal that creates the correct filename only for the first fragment".
> Basically I have to remove all close invokes of GST Objects (try (....) resources). (I had other listeners that where closing objects using java try resources and this method)
> As I could see, this closable method removes all signal event from the pipeline causing the issue.

Sure, don't close (dispose) objects you're still using!

The library has automated memory management. Most of the time, you
can just leave it to it. You can manually dispose via close() /
dispose() or try with resources in circumstances where it's useful to
eagerly release things. But you need to know what objects you're
doing that with, as well as the one-to-one mapping of GObjects to Java
Objects, and not release things that are in use or you expect to get
signals from. If you release the pipeline itself while it's in use,
you may also cause corruption or a crash.

Best wishes,

Neil

--
Neil C Smith
Codelerity Ltd.
www.codelerity.com

Codelerity Ltd. is a company registered in England and Wales
Registered company number : 12063669

Registered office address : 3rd Floor Suite, 207 Regent Street,
London, W1B 3HH, England