bug#70914: 29.3; Crashes often on Windows

["Simen Endsjø" <simendsjo@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2050 bytes --]

> From reading just this source file I'm not sure emacs supports long paths.
> How long is your path? Maybe you can show what it looks like?

D:/profiles/system.org

On Wed, May 22, 2024, 06:32 Hannes Domani <ssbssa@yahoo.de> wrote:

>  Am Dienstag, 21. Mai 2024 um 22:32:04 MESZ hat Simen Endsjø <
> simendsjo@gmail.com> Folgendes geschrieben:
>
> > Look at that! I tried running it twice, and it reported the same
> location both
> > times.
> >
> > This is when opening my "system.org" file. My D: is a VHD DevDrive
> > (ReFs), but I have experiencing crashes since way before I migrated to a
> > DevDrive.
> >
> > I have some symlinked folders further down the tree too. And Developer
> Mode
> > enabled which allows me to register symlinks without admin rights.
> >
> > I have LongPathsEnabled, ref
> >
> https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=registry
>
>
> >     Thread 1 received signal SIGSEGV, Segmentation fault.
> >     0x0000000000000000 in ?? ()
> >     (gdb) bt
> >     #0  0x0000000000000000 in ?? ()
> >     #1  0x0000000000000000 in ?? ()
> >     (gdb) reverse-stepi
> >     0x00007ff7beeabe9d in get_volume_info (name=<unavailable>,
> > pPath=<unavailable>) at w32.c:3502
> >     3502    }
> >             ^
> >     (gdb) bt
> >     #0  0x00007ff7beeabe9d in get_volume_info (name=<unavailable>,
> > pPath=<unavailable>) at w32.c:3502
> >     #1  0x0000000000000000 in ?? ()
> >     Backtrace stopped: not enough registers or memory available to
> > unwind further
>
> From reading just this source file I'm not sure emacs supports long paths.
> How long is your path? Maybe you can show what it looks like?
>
> There might be a buffer overflow happening in get_volume_info(), this
> line looks suspicious to me:
> 3488      strncpy (temp, name, root_len);
>
> If it turns out the problem is not in get_volume_info(), you might have
> to step further back with 'reverse-next' to see where it was called from.
>
>
> Hannes
>

[-- Attachment #2: Type: text/html, Size: 3165 bytes --]