Happened on Windows, but it should happen both on Windows and Linux

elemount can you share the query that you are running.
I tried the query

set use_stat_tables='preferably';

select * from performance_schema.objects_summary_global_by_type;

and it does not crash.

Also we had https://jira.mariadb.org/browse/MDEV-16507 which made sure that we don't read statistics for table.

for (TABLE_LIST *tl= tables; tl; tl= tl->next_global)

  {

    if (!tl->is_view_or_derived() && !is_temporary_table(tl) && tl->table)

    {

      TABLE_SHARE *table_share= tl->table->s;

      if (table_share && 

          table_share->table_category != TABLE_CATEGORY_USER

          && is_stat_table(&tl->db, &tl->alias))

        return FALSE;

    }

  }

there is a condition that is !is_temporary_table(tl)

@Varun, it happened when the "optimizer_use_condition_selectivity=4". In this condition, it try to call read_histograms_for_table and thus crash.

elemount the above observations were with optimizer_use_condition_selectivity=4, I even checked 10.4 where optimizer_use_condition is set to 4 by default

This is what I get when i run on 10.2

MariaDB [test]> set use_stat_tables='preferably';

Query OK, 0 rows affected (0.00 sec)

MariaDB [test]> set optimizer_use_condition_selectivity=4;

Query OK, 0 rows affected (0.00 sec)

MariaDB [test]> select * from performance_schema.objects_summary_global_by_type;

Empty set (0.00 sec)

Can you share the query and also the entire stack trace?

11 00000005`6096a800 00000005`01596baf mysqld!alloc_histograms_for_table_share+0x9c [d:\src\sql\sql_statistics.cc @ 2410]
12 00000005`6096a880 00000005`01597ac6 mysqld!read_histograms_for_table+0x6f [d:\src\sql\sql_statistics.cc @ 3210]
13 00000005`6096b8d0 00000005`01548ace mysqld!read_statistics_for_tables_if_needed+0x196 [d:\src\sql\sql_statistics.cc @ 3294]
14 00000005`6096cb90 00000005`01308b02 mysqld!open_and_lock_tables+0x7e [d:\src\sql\sql_base.cc @ 4732]
15 00000005`6096cbf0 00000005`01531f32 mysqld!open_and_lock_tables+0x42 [d:\src\sql\sql_base.h @ 500]
16 00000005`6096cc40 00000005`014bd8e8 mysqld!mysql_execute_command+0x2362 [d:\src\sql\sql_parse.cc @ 4529]
17 00000005`6096d900 00000005`014c1751 mysqld!sp_instr_stmt::exec_core+0x18 [d:\src\sql\sp_head.cc @ 3248]
18 00000005`6096d930 00000005`014be583 mysqld!sp_lex_keeper::reset_lex_and_exec_core+0xf1 [d:\src\sql\sp_head.cc @ 3009]
19 00000005`6096d980 00000005`014bdd87 mysqld!sp_instr_stmt::execute+0xd3 [d:\src\sql\sp_head.cc @ 3162]
1a 00000005`6096d9e0 00000005`014bf1e7 mysqld!sp_head::execute+0x3c7 [d:\src\sql\sp_head.cc @ 1327]
1b 00000005`6096dd20 00000005`0152cc68 mysqld!sp_head::execute_procedure+0x407 [d:\src\sql\sp_head.cc @ 2116]
1c 00000005`6096ddf0 00000005`0153403d mysqld!do_execute_sp+0xa8 [d:\src\sql\sql_parse.cc @ 2930]
1d (Inline Function) -------`------- mysqld!THD::enter_stage+0x35db [d:\src\sql\sql_class.h @ 2321]
1e 00000005`6096de20 00000005`01535020 mysqld!mysql_execute_command+0x446d [d:\src\sql\sql_parse.cc @ 6340]
1f 00000005`6096eae0 00000005`0152b816 mysqld!mysql_parse+0x190 [d:\src\sql\sql_parse.cc @ 8169]
20 00000005`6096eb40 00000005`0152cb40 mysqld!dispatch_command+0xb06 [d:\src\sql\sql_parse.cc @ 1841]
21 00000005`6096fb30 00000005`016329f3 mysqld!do_command+0x1b0 [d:\src\sql\sql_parse.cc @ 1386]
22 00000005`6096fba0 00000005`01632b60 mysqld!threadpool_process_request+0x53 [d:\src\sql\threadpool_common.cc @ 366]

Source code is based on 10.2.22

And call on the table performance_schema.events_statements_summary_by_digest

Could you please provide the test case to demonstrate the problem and your configuration of the server.

elemount for your information, MDEV-19352 has a similar stack trace as your case and I think the fix for it would also solve your issue. It is pushed to 10.1 and would be merged upwards.
Can you check if that fixes the issue for you too?