I've managed to reproduce this with trunk gdb.

With system gdb 13.2, I get this:
...
$ gdb --batch -ex "b test.d:4" -ex "run" -ex "p data" ./test
Breakpoint 1 at 0x438839: file ./test.d, line 4.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Breakpoint 1, _Dmain () at ./test.d:4
4	    return 0;
$1 = <error reading variable: value requires 1000000 bytes, which is more than max-value-size>
...

Reproduced with gdb-15-branch and gdb-14-branch, doesn't reproduce with gdb-13-branch.

Bisects to:
...
commit a0c07915778486a950952139d27c01d4285b02b4
Author: Andrew Burgess <andrew.burgess@embecosm.com>
Date:   Fri Feb 10 23:49:19 2023 +0000

    GDB: Introduce limited array lengths while printing values
...

This can also be reproduce with C:
```
char a[1000000];

int main()
{
  return a[0];
}
```

No problem with 'print', but 'output' crashes:
```
(gdb) print a
$1 = {0 '\000' <repeats 65536 times>, <unavailable> <repeats 934464 times>}
(gdb) output a

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
```

(In reply to Hannes Domani from comment #4)
> This can also be reproduce with C:

Using this patch:
...
diff --git a/gdb/printcmd.c b/gdb/printcmd.c
index e37e30edb87..7e6ca7dcf15 100644
--- a/gdb/printcmd.c
+++ b/gdb/printcmd.c
@@ -1449,6 +1449,8 @@ output_command (const char *exp, int from_tty)
      need to load as many array elements as we plan to print.  */
   scoped_array_length_limiting limit_large_arrays (opts.print_max);
 
+  val->fetch_limited ();
+
   print_formatted (val, fmt.size, &opts, gdb_stdout);
 
   annotate_value_end ();
diff --git a/gdb/value.c b/gdb/value.c
index 09fb19b9bf8..2f600794148 100644
--- a/gdb/value.c
+++ b/gdb/value.c
@@ -1687,13 +1687,8 @@ value::set_component_location (const struct value *whole)
     }
 }
 
-/* Access to the value history.  */
-
-/* Record a new value in the value history.
-   Returns the absolute history index of the entry.  */
-
-int
-value::record_latest ()
+void
+value::fetch_limited ()
 {
   /* We don't want this value to have anything to do with the inferior anymore.
      In particular, "set $1 = 50" should not affect the variable from which
@@ -1719,6 +1714,17 @@ value::record_latest ()
   ULONGEST limit = m_limited_length;
   if (limit != 0)
     mark_bytes_unavailable (limit, m_enclosing_type->length () - limit);
+}
+
+/* Access to the value history.  */
+
+/* Record a new value in the value history.
+   Returns the absolute history index of the entry.  */
+
+int
+value::record_latest ()
+{
+  fetch_limited ();
 
   /* Mark the value as recorded in the history for the availability check.  */
   m_in_history = true;
diff --git a/gdb/value.h b/gdb/value.h
index 13cfb007aa2..e697a7a9301 100644
--- a/gdb/value.h
+++ b/gdb/value.h
@@ -638,6 +638,8 @@ struct value
 					LONGEST bit_offset,
 					LONGEST bit_length);
 
+  void fetch_limited ();
+
   /* Record this value on the value history, and return its location
      in the history.  The value is removed from the value chain.  */
   int record_latest ();
...
I get:
...
$ gdb -q -batch a.out -ex "print a" -ex "output a"
$1 = {0 '\000' <repeats 65536 times>, <unavailable> <repeats 934464 times>}
{0 '\000' <repeats 65536 times>, <unavailable> <repeats 934464 times>}$ 
...

Aha, and this bit:
...
      /* We know that this is a _huge_ array, any attempt to fetch this                                               
         is going to cause GDB to throw an error.  However, to allow                                                  
         the array to still be displayed we fetch its contents up to                                                  
         `max_value_size' and mark anything beyond "unavailable" in                                                   
         the history.  */
      if (m_type->code () == TYPE_CODE_ARRAY
          && m_type->length () > max_value_size
          && array_length_limiting_element_count.has_value ()
          && m_enclosing_type == m_type
          && calculate_limited_array_length (m_type) <= max_value_size)
        m_limited_length = max_value_size;
...
doesn't trigger for the d example because m_type->code () is not TYPE_CODE_ARRAY but TYPE_CODE_STRUCT, more specifically:
...
(gdb) ptype data
type = struct _Array_unsigned char {
    ulong length;
    ubyte *ptr;
}
...

How about something like this:
```
diff --git a/gdb/value.c b/gdb/value.c
index 424a1048dd2..bca733b95de 100644
--- a/gdb/value.c
+++ b/gdb/value.c
@@ -1717,10 +1717,6 @@ value::record_latest ()
       fetch_lazy ();
     }
 
-  ULONGEST limit = m_limited_length;
-  if (limit != 0)
-    mark_bytes_unavailable (limit, m_enclosing_type->length () - limit);
-
   /* Mark the value as recorded in the history for the availability check.  */
   m_in_history = true;
 
@@ -3932,6 +3928,11 @@ value::fetch_lazy_memory ()
   if (len > 0)
     read_value_memory (this, 0, stack (), addr,
 		       contents_all_raw ().data (), len);
+
+  /* If only part of an array was loaded, mark the rest as unavailable.  */
+  if (m_limited_length > 0)
+    mark_bytes_unavailable (m_limited_length,
+			    m_enclosing_type->length () - m_limited_length);
 }
 
 /* See value.h.  */
```

This would make sure that the contents always match the unavailable bytes, and not only when being 'output' or added to the value history.

(In reply to Hannes Domani from comment #7)
> How about something like this:

It works for both the c and d example, and doesn't cause regressions on x86_64-linux, so LGTM.  Thanks for working on this, and please submit this fix.

(In reply to Tom de Vries from comment #8)
> It works for both the c and d example, and doesn't cause regressions on
> x86_64-linux, so LGTM.  Thanks for working on this, and please submit this
> fix.

Done:
https://sourceware.org/pipermail/gdb-patches/2024-August/210857.html

The master branch has been updated by Hannes Domani <ssbssa@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=8fdd2b2bcd8117cafcc6ef976e45f0d9f95fb528

commit 8fdd2b2bcd8117cafcc6ef976e45f0d9f95fb528
Author: Hannes Domani <ssbssa@yahoo.de>
Date:   Tue Aug 6 19:34:18 2024 +0200

    Mark unavailable bytes of limited-length arrays when allocating contents
    
    Using 'output' to print arrays larger than max-value-size, with only
    repeating elements, can cause gdb to crash:
    ```
    $ cat a.c:
    char a[1000000];
    
    int main()
    {
      return a[0];
    }
    $ gdb -q a
    (gdb) print a
    $1 = {0 '\000' <repeats 65536 times>, <unavailable> <repeats 934464 times>}
    (gdb) output a
    
    This application has requested the Runtime to terminate it in an unusual way.
    Please contact the application's support team for more information.
    ```
    
    Using 'print' works, because value::record_latest sets the unavailable
    bytes of the value when it's added to the value history.
    But 'outout' doesn't do that, so the printing tries to access more bytes
    than are available.
    
    The original problem in PR32015 was about using 'print' of a dynamic
    array in a D program.
    Here the crash happens because for 'print' the value was a struct with
    length/ptr fields, which is converted in d-valprint.c into an array.
    So value::record_latest didn't have a chance to mark the unavailable
    bytes in this case.
    
    To make sure the unavailable bytes always match the contents, this fixes
    it by marking the unavailable bytes immediately after the contents are
    allocated.
    
    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32015
    Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
    Approved-By: Andrew Burgess <aburgess@redhat.com>

Fixed.

The gdb-15-branch branch has been updated by Tom de Vries <vries@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=b82263060348ed854c03806675de34f70562044b

commit b82263060348ed854c03806675de34f70562044b
Author: Hannes Domani <ssbssa@yahoo.de>
Date:   Wed Aug 7 15:05:06 2024 +0200

    Mark unavailable bytes of limited-length arrays when allocating contents
    
    Using 'output' to print arrays larger than max-value-size, with only
    repeating elements, can cause gdb to crash:
    ```
    $ cat a.c:
    char a[1000000];
    
    int main()
    {
      return a[0];
    }
    $ gdb -q a
    (gdb) print a
    $1 = {0 '\000' <repeats 65536 times>, <unavailable> <repeats 934464 times>}
    (gdb) output a
    
    This application has requested the Runtime to terminate it in an unusual way.
    Please contact the application's support team for more information.
    ```
    
    Using 'print' works, because value::record_latest sets the unavailable
    bytes of the value when it's added to the value history.
    But 'outout' doesn't do that, so the printing tries to access more bytes
    than are available.
    
    The original problem in PR32015 was about using 'print' of a dynamic
    array in a D program.
    Here the crash happens because for 'print' the value was a struct with
    length/ptr fields, which is converted in d-valprint.c into an array.
    So value::record_latest didn't have a chance to mark the unavailable
    bytes in this case.
    
    To make sure the unavailable bytes always match the contents, this fixes
    it by marking the unavailable bytes immediately after the contents are
    allocated.
    
    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32015
    Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
    Approved-By: Andrew Burgess <aburgess@redhat.com>
    (cherry picked from commit 8fdd2b2bcd8117cafcc6ef976e45f0d9f95fb528)