0

Querying a very large table using Entity to SQL, works fine in all other parts of code and even works the first time. However, on the second time of performing an identical request, it will give a stack overflow exception. When breaking up the linq query - it happens on the .FirstOrDefault()

I believe that is when linq triggers the query to happen, such as how .ToList() kicks off the query.

I'm just confused on why a stack overflow exception would happen on a non-recursion call, as there are only 3 methods in the call stack. Since it happens on the second call every time, maybe it is building onto an existing stack outside of the scope, or maybe there is something in memory from the previous call to the DB. Anyone have any tips? let me know if I can add additional info... thank you

Small code example:

int myId = context.TABLE_NAME.Where(x => x.ID == myId).FirstOrDefault().ID;

where TABLE_NAME is a very large table, 300+ million records, and inside of the table class it does have an unusual constructor that I have not seen in most entity classes.

    public partial class TABLE_NAME
    {
        [System.Diagnostics.CodeAnalysis.SuppressMessage("Microsoft.Usage", "CA2214:DoNotCallOverridableMethodsInConstructors")]
        public TABLE_NAME()
        {
            this.OTHER_TABLE_NAME = new HashSet<OTHER_TABLE_NAME >();
        }
    
        public int ID { get; set; }
        ...
       

        [System.Diagnostics.CodeAnalysis.SuppressMessage("Microsoft.Usage", "CA2227:CollectionPropertiesShouldBeReadOnly")]
        public virtual ICollection<OTHER_TABLE_NAME> OTHER_TABLE_NAME{ get; set; }
    }
wawo
  • 37
  • 1
  • 8
  • Don't call `.ToList()`, in tries to materialize all the data. – Roman Ryzhiy Dec 07 '22 at 17:08
  • https://stackoverflow.com/questions/15516462/is-there-a-performance-impact-when-calling-tolist – Roman Ryzhiy Dec 07 '22 at 17:10
  • @RomanRyzhiy that was an example, .ToList() loads in the objects - I was saying that maybe the exception is thrown during .FirstOrDefault() because it loads in the objects as well? – wawo Dec 07 '22 at 17:12
  • Could you provide a code example of the lines around your error? – Leon Bohmann Dec 07 '22 at 17:18
  • 1
    We can only sympathise. Which query, which code, which ORM version, everything counts. LINQ Translator itself is very complicated piece of code, full of recursions. But maybe you have big `Where` dynamically generated (just idea). – Svyatoslav Danyliv Dec 07 '22 at 17:27
  • @LeonBohmann I have attached a simplified code example – wawo Dec 07 '22 at 17:29
  • 1
    I'm curious about the "CA2214:DoNotCallOverridableMethodsInConstructors" suppress attribute. You aren't calling any overridable methods. Badly constructed overridable methods can blow out the stack. You can usually debug stack overflows. See if you can scroll back through the exception's stack to see a repeating pattern. Failing that, sprinkle some breakpoints in your code see if a pattern emerges. One common cause of SOs is a non-automatic property that treats itself as if it was a backing store for the property – Flydog57 Dec 07 '22 at 17:35
  • Your code example will not help. Try to catch in debugger call stack. – Svyatoslav Danyliv Dec 07 '22 at 17:52
  • The fact that there are warning suppressions around recursion screams that there is a dangerous configuration inside the entity definition where one property self-referencing or is likely calling another property with a cyclic reference that you either don't understand what is happening or trying to do something clever that EF will get tripped up about. You can try to dance around the problem ensuring you use `Select` or other operations, your "small example" would be completely pointless as you already HAVE the ID. Maybe revise your question with a proper example. – Steve Py Dec 07 '22 at 20:58

0 Answers0