当前位置: 首页 > 知识库问答 >
问题:

Java中的wiringPiISR核心转储

陶成济
2023-03-14

我用wiringPiISR#得到了一个核心转储

Java运行时环境检测到一个致命错误:#Internal error(os_linux_zero.cpp:254),PID=6552,TID=1866855520致命错误:捕获未处理信号11

import com.na7kr.GPIOController.GPIOController;
import com.na7kr.Utils.Utils;
import com.na7kr.rpi_gpio_controller.Rpi_gpio_controllerApplicationUI;

import com.pi4j.wiringpi.Gpio;
import com.pi4j.wiringpi.GpioInterruptCallback;

public class Interrupt {
Rpi_gpio_controllerApplicationUI mApplication = new      Rpi_gpio_controllerApplicationUI(); // NO_UCD
                                                                                        // (use
                                                                                        // private)

// ***************************************
public synchronized void GetInput1(int trigerpin, int outputpin) throws InterruptedException {
    System.out.println("<--Pi4J--> GPIO interrupt test program");

    // setup wiringPi
    if (Gpio.wiringPiSetup() == -1) {
        System.out.println(" ==>> GPIO SETUP FAILED");
        return;
    }

    Gpio.pinMode(1, Gpio.INPUT);
    Gpio.pinMode(2, Gpio.INPUT);

    Gpio.pullUpDnControl(1, Gpio.PUD_UP);
    Gpio.pullUpDnControl(2, Gpio.PUD_UP);

    Gpio.wiringPiISR(1, Gpio.INT_EDGE_FALLING, new GpioInterruptCallback() {
        @Override
        public void callback(int pin) {
            System.out.println(" ==>> GPIO PIN " + pin + " - INTERRUPT DETECTED");
            Utils.Output_WriteDebug(true, "1");
            GPIOController.INSTANCE.mGPIOPins[outputpin].toggle();
            mApplication.refreshGPIOPinState();
            Utils.Output_WriteDebug(true, "2");
        }
    });
    Gpio.wiringPiISR(2, Gpio.INT_EDGE_FALLING, new GpioInterruptCallback() {
        @Override
        public void callback(int pin) {
            System.out.println(" ==>> GPIO PIN " + pin + " - INTERRUPT DETECTED");
            Utils.Output_WriteDebug(true, "3");
            GPIOController.INSTANCE.mGPIOPins[outputpin].toggle();
            mApplication.refreshGPIOPinState();
            Utils.Output_WriteDebug(true, "4");
        }
    });
}
}
---------------  T H R E A D  ---------------

Current thread (0x017210c0):  JavaThread "Thread-4" [_thread_in_vm, id=7296, stack(0x6ec61000,0x6f460000)]

Stack: [0x6ec61000,0x6f460000],  sp=0x6f45e708,  free space=8181k

---------------  P R O C E S S  ---------------

Java Threads: ( => current thread )
=>0x017210c0 JavaThread "Thread-4" [_thread_in_vm, id=7296, stack(0x6ec61000,0x6f460000)]
  0x71cf8a88 JavaThread "http-bio-8080-exec-10" daemon [_thread_blocked, id=6582, stack(0x6fd60000,0x6fee0000)]
  0x63c19bd8 JavaThread "http-bio-8080-exec-9" daemon [_thread_in_native, id=6581, stack(0x6fee0000,0x70060000)]
  0x73407170 JavaThread "http-bio-8080-exec-8" daemon [_thread_in_native, id=6580, stack(0x70060000,0x701e0000)]
  0x74069a48 JavaThread "http-bio-8080-exec-7" daemon [_thread_in_native, id=6579, stack(0x701e0000,0x70360000)]
  0x73e3b720 JavaThread "http-bio-8080-exec-6" daemon [_thread_in_native, id=6578, stack(0x70460000,0x705e0000)]
  0x734058a0 JavaThread "http-bio-8080-exec-5" daemon [_thread_blocked, id=6577, stack(0x70818000,0x70998000)]
  0x734045a0 JavaThread "http-bio-8080-exec-4" daemon [_thread_in_native, id=6576, stack(0x70998000,0x70b18000)]
  0x734032a0 JavaThread "http-bio-8080-exec-3" daemon [_thread_in_native, id=6575, stack(0x70b18000,0x70c98000)]
  0x73402110 JavaThread "http-bio-8080-exec-2" daemon [_thread_in_native, id=6574, stack(0x70c98000,0x70e18000)]
  0x73400a98 JavaThread "http-bio-8080-exec-1" daemon [_thread_blocked, id=6573, stack(0x70e18000,0x70f98000)]
  0x72b80b20 JavaThread "http-bio-8080-AsyncTimeout" daemon [_thread_blocked, id=6572, stack(0x70f98000,0x71118000)]
  0x72b7fa90 JavaThread "http-bio-8080-Acceptor-0" daemon [_thread_in_native, id=6571, stack(0x71118000,0x71298000)]
  0x71f8a4a8 JavaThread "ContainerBackgroundProcessor[StandardEngine[Catalina]]" daemon [_thread_blocked, id=6570, stack(0x71298000,0x71418000)]
  0x71c373f0 JavaThread "GC Daemon" daemon [_thread_blocked, id=6567, stack(0x71a80000,0x71c00000)]
  0x72c3e9d8 JavaThread "Service Thread" daemon [_thread_blocked, id=6564, stack(0x720f7000,0x72277000)]
  0x72c3d058 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=6563, stack(0x72277000,0x723f7000)]
  0x72c3bd30 JavaThread "Surrogate Locker Thread (Concurrent GC)" daemon [_thread_blocked, id=6562, stack(0x723f7000,0x72577000)]
  0x72c1fe58 JavaThread "Finalizer" daemon [_thread_blocked, id=6561, stack(0x72700000,0x72880000)]
  0x72c1ea18 JavaThread "Reference Handler" daemon [_thread_blocked, id=6560, stack(0x72880000,0x72a00000)]
  0x76505f78 JavaThread "main" [_thread_in_native, id=6553, stack(0x76660000,0x767df000)] 

共有1个答案

澹台景山
2023-03-14

我改成了PI4J的1.1-snapshot,问题就消失了。

 类似资料:
  • 问题内容: 每当进程崩溃时,我都想创建一个核心转储。目前,我正在采用这种方法: 使用gcc / g ++的“ -g”构建程序的特殊“调试”版本。 执行“ ulimit -c unlimited” 现在,只要程序崩溃,我们就获得核心转储。 但我想减少步骤数,以便: 应始终创建核心转储。即使是“发布”版本。不应要求用户手动执行命令“ ”。 该核心转储的回溯应该能够给出调用的文件,函数,行号。那是人类可

  • 问题内容: 运行C程序时,它显示 “((核心转储)”), 但是在当前路径下看不到任何文件。 我已经设置并验证了: 我也试图找到一个名为“ core”的文件,但是没有得到core dumped文件? 任何帮助,我的核心文件在哪里? 问题答案: 阅读/usr/src/linux/Documentation/sysctl/kernel.txt。 [/ proc / sys / kernel /] cor

  • .NET核心和ASP.NET核心到底有什么区别?

  • 问题内容: 我需要一种 从应用程序内部 请求堆转储 的方法 。 基本原理:当遇到特定的错误情况时,我想转储堆,以便可以看到内存中有什么内容。 但是我想使它自动化(例如,当我检测到某些特定情况发生时。或者当看门狗不再收到ping命令时;当某些测试失败时)。因此,我需要一种从应用程序本身内部转储堆的方法。我似乎无法通过MX bean的东西找到它。尽管MX Bean可以通过监视器和“可拥有的同步器”信息

  • 问题内容: 每次我的应用程序崩溃时,都不会生成核心转储文件。我记得几天前,它 是 在另一台服务器 上 生成的。我正在使用bash屏幕运行应用程序,如下所示: 如您所见,如果要生成核心转储,则在使用哪个选项很重要,但是当遇到分段错误时,它仍然不会生成。我该如何运作? 问题答案: 确保当前目录(崩溃时可能会更改目录)是可写的。如果服务器调用,则该目录必须是该用户可写的。 同时检查。这可能会将核心转储重

  • 我试图用Java编写一个串行通信类,它将使用Java Simple serial Connector库连接到Arduino UNO。然而,每当我试图打开端口时,我都会在本机代码中遇到这个错误: # #Java运行时环境检测到一个致命错误: # #exception_access_visire(0xC0000005)at pc=0x0000006EC4B5BB,PID=6324,TID=6508 #