Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.misc > #88701 > unrolled thread

write once, run anywhere: bah

Back to article view | Back to comp.os.linux.misc

Contents

  write once, run anywhere: bah Eli the Bearded <*@eli.users.panix.com> - 2026-07-06 01:38 +0000
    Re: write once, run anywhere: bah c186282 <c186282@nnada.net> - 2026-07-06 06:47 -0400
    Re: write once, run anywhere: bah Nelyon283 <nelyon2034829430274@noemail.invalid.invalid> - 2026-07-06 16:46 +0000

#88701 — write once, run anywhere: bah

I have a piece of software, to drive a USB camera, that ran fine on
Ubuntu 20.04 but is segfaulting on Debian 13. It's something to do with
the "libuvc" library. Before I installed libuvc0
(libuvc0_0.0.7-3_amd64.deb), it ran but with an all white window and an
error message about libuvc to stdout. Now it crashes almost immediagely:

Stack: [0x00007fdf89d00000,0x00007fdf89e00000],  sp=0x00007fdf89dfe4a8, free space=1017k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [libuvc.so.0+0xaa48]  uvc_get_format_descs+0x8
C  [libHelloJni.so+0xb1b8]  Java_HelloJni_getResolutions+0x195
j  HelloJni.getResolutions(LCamera;)[LResolution;+0
j  Visualizer.init()V+7887
j  Visualizer.main([Ljava/lang/String;)V+348
v  ~StubRoutines::call_stub 0x00007fdf73d37cc6
V  [libjvm.so+0x9377ca]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x2da V  [libjvm.so+0x9e3175]  jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher *, JavaThread*) [clone .constprop.1]+0x365
V  [libjvm.so+0x9f5502]  jni_CallStaticVoidMethod+0x252
C  [libjli.so+0x522b]  JavaMain+0xf4b
C  [libjli.so+0x826d]  ThreadJavaMain+0xd
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  HelloJni.getResolutions(LCamera;)[LResolution;+0
j  Visualizer.init()V+7887
j  Visualizer.main([Ljava/lang/String;)V+348
v  ~StubRoutines::call_stub 0x00007fdf73d37cc6
 
siginfo: si_signo: 11 (SIGSEGV), si_code: 128 (SI_KERNEL), si_addr: 0x0000000000000000

So happy to have what I thought would be an upgrade proof piece of
software fail so quickly.

When I purchased this, I thought the "works with Linux" meant it worked
like a regular webcam, not "requires special software". I would not have
bought it knowing it needed special software.

The company to avoid is Ipevo, and the camera to avoid is the V4K.

Elijah
------
a pox on proprietary interfaces

[toc] | [next] | [standalone]

#88707

On 7/5/26 21:38, Eli the Bearded wrote:
> I have a piece of software, to drive a USB camera, that ran fine on
> Ubuntu 20.04 but is segfaulting on Debian 13. It's something to do with
> the "libuvc" library. Before I installed libuvc0
> (libuvc0_0.0.7-3_amd64.deb), it ran but with an all white window and an
> error message about libuvc to stdout. Now it crashes almost immediagely:
> 
> Stack: [0x00007fdf89d00000,0x00007fdf89e00000],  sp=0x00007fdf89dfe4a8, free space=1017k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> C  [libuvc.so.0+0xaa48]  uvc_get_format_descs+0x8
> C  [libHelloJni.so+0xb1b8]  Java_HelloJni_getResolutions+0x195
> j  HelloJni.getResolutions(LCamera;)[LResolution;+0
> j  Visualizer.init()V+7887
> j  Visualizer.main([Ljava/lang/String;)V+348
> v  ~StubRoutines::call_stub 0x00007fdf73d37cc6
> V  [libjvm.so+0x9377ca]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x2da V  [libjvm.so+0x9e3175]  jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher *, JavaThread*) [clone .constprop.1]+0x365
> V  [libjvm.so+0x9f5502]  jni_CallStaticVoidMethod+0x252
> C  [libjli.so+0x522b]  JavaMain+0xf4b
> C  [libjli.so+0x826d]  ThreadJavaMain+0xd
> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
> j  HelloJni.getResolutions(LCamera;)[LResolution;+0
> j  Visualizer.init()V+7887
> j  Visualizer.main([Ljava/lang/String;)V+348
> v  ~StubRoutines::call_stub 0x00007fdf73d37cc6
>   
> siginfo: si_signo: 11 (SIGSEGV), si_code: 128 (SI_KERNEL), si_addr: 0x0000000000000000
> 
> So happy to have what I thought would be an upgrade proof piece of
> software fail so quickly.
> 
> When I purchased this, I thought the "works with Linux" meant it worked
> like a regular webcam, not "requires special software". I would not have
> bought it knowing it needed special software.
> 
> The company to avoid is Ipevo, and the camera to avoid is the V4K.


   Device drivers have always been the bane of
   computing - but there's really no way around
   the damned things. No such thing as a "universal
   device interface".

   Maybe could be, but WOW the complexity ! It'd
   also have to be built into every device - 500
   little boxes to fill in, so to speak.

   As for USB cameras - I have a lot of those. Never
   really had many issues. Most IP cams have a web
   interface built in and the rest are just kinda
   plug-n-play. V4L2 works pretty well for setting
   the usual video params afterwards.

   Oh, try running "cheese" and then try the cam
   again. Sometimes the /dev/video(x) may not 'take'
   until something like cheese uses it. This is SOP
   with software like 'motion'.

[toc] | [prev] | [next] | [standalone]

#88723

On Mon, 6 Jul 2026 01:38:21 -0000 (UTC), Eli the Bearded wrote:

> I have a piece of software, to drive a USB camera, that ran fine on
> Ubuntu 20.04 but is segfaulting on Debian 13. It's something to do with
> the "libuvc" library. Before I installed libuvc0
> (libuvc0_0.0.7-3_amd64.deb), it ran but with an all white window and an
> error message about libuvc to stdout. Now it crashes almost immediagely:
> 
> Stack: [0x00007fdf89d00000,0x00007fdf89e00000],  sp=0x00007fdf89dfe4a8,
> free space=1017k Native frames: (J=compiled Java code, j=interpreted,
> Vv=VM code, C=native code)
> C  [libuvc.so.0+0xaa48]  uvc_get_format_descs+0x8 C 
> [libHelloJni.so+0xb1b8]  Java_HelloJni_getResolutions+0x195 j 
> HelloJni.getResolutions(LCamera;)[LResolution;+0 j 
> Visualizer.init()V+7887 j  Visualizer.main([Ljava/lang/String;)V+348 v 
> ~StubRoutines::call_stub 0x00007fdf73d37cc6 V  [libjvm.so+0x9377ca] 
> JavaCalls::call_helper(JavaValue*, methodHandle const&,
> JavaCallArguments*, JavaThread*)+0x2da V  [libjvm.so+0x9e3175] 
> jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType,
> _jmethodID*, JNI_ArgumentPusher *, JavaThread*) [clone
> .constprop.1]+0x365 V  [libjvm.so+0x9f5502] 
> jni_CallStaticVoidMethod+0x252 C  [libjli.so+0x522b]  JavaMain+0xf4b C 
> [libjli.so+0x826d]  ThreadJavaMain+0xd Java frames: (J=compiled Java
> code, j=interpreted, Vv=VM code)
> j  HelloJni.getResolutions(LCamera;)[LResolution;+0 j 
> Visualizer.init()V+7887 j  Visualizer.main([Ljava/lang/String;)V+348 v 
> ~StubRoutines::call_stub 0x00007fdf73d37cc6
>  
> siginfo: si_signo: 11 (SIGSEGV), si_code: 128 (SI_KERNEL), si_addr:
> 0x0000000000000000
> 
> So happy to have what I thought would be an upgrade proof piece of
> software fail so quickly.
> 
> When I purchased this, I thought the "works with Linux" meant it worked
> like a regular webcam, not "requires special software". I would not have
> bought it knowing it needed special software.
> 
> The company to avoid is Ipevo, and the camera to avoid is the V4K.
> 
> Elijah ------
> a pox on proprietary interfaces

"Works with Linux", only if you are running an outdated version of the OS 
from 2020. Makes sense for such a company to build a proprietary driver 
that they likely didn't update in six years and that they thought it was a 
good idea to ship because it worked on a single internal machine.
To me, they are scumbags.

If you're here for a technical explanation, then it's likely that the 
libuvc library was updated in a way breaking the proprietary driver's 
hardcoded assumptions about memory layout or something like that.


-- 
I use Linux

[toc] | [prev] | [standalone]

Back to top | Article view | comp.os.linux.misc

csiph-web